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Beschreibung 



Verfahren, Anordnung und Sat:z mehrerer Anordnungen zur Behe- 
5 bung mindestens einer Inkonsistenz in einer Datenbankmenge, 
die eine Datenbank sowie mindestens eine Kopiedatenbank der 
Datenbank aufweist 

Die Erfindung betrifft ein Verfahren, eine Anordnung sowie 
10 einen Satz mehrerer Anordnungen zur Behebung mindestens einer 
Inkonsistenz in einer Datenbankmenge, die eine Datenbank so- 
wie mindestens eine Kopiedatenbank der Datenbank aufweist . 

Ein solches Verfahren ist aus [1] bekannt. 
15 

Bei dem aus [1] bekannten Verfahren kommunizieren Rechner 
uber ein Kommunikationsnetz unter Verwendung eines Kommunika- 
tionsprotokolls miteinander . 

20 Unter einem Kommunikationsnetz ist beispielsweise ein Daten- 
netz, ein Funknetz Oder auch ein ubliches Telefonnetz zu ver- 
stehen . 

Unter einem Kommunikationsprotokoll ist ein Protokoll zur 
5 Festlegung des Datenformats zu verstehen, welches im Rahmen 
einer Kommunikation zwischen den Rechnern verwendet wird. Ein 
solches Kommunikationsprotokoll ist beispielsweise das Trans- 
port Control Protocol/Internet Protocol (TCP/IP) . 

30 Bei dem Verfahren aus [1] sind in einem ersten Rechner eine 

Datenbank und in jedem weiteren Rechner eine Kopie der Daten- 
bank, im weiteren als Kopiedatenbank bezeichhet, gespeichert. 

Die Datenbank bzw. die Kopiedatenbanken werden im Rahmen ei- 
35 ner Sitzung von jeweils einem Rechner verandert, d.h. die in 
der Datenbank bzw. einer Kopiedatenbank enthaltenen Daten 
bzw. deren Struktur werden verandert. 
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Unter einer Datenbank ist in diesem Zusammenhang beispiels- 
weise eine hierarchische oder auch eine obj ektorientierte Da- 
tenbank 2u verstehen. 

Eine Datenbank enthalt Daten, die gemaii einer vorgegebenen 
Struktur gespeichert sind und miteinander in Zusammenhang 
stehen. Jedes Objekt, d.h. jeder Datensatz innerhalb der Da- 
tenbank ist Ublicherweise iiber einen Identif ikator 
( Identifier) eindeutig identif izierbar . 

Es kommt vor, daii Anderungen an einer Kopiedatenbank vorge- 
nommen werden, ohne daii dieselbe Anderung auch in der Daten- 
bank selbst erfolgt oder auch umgekehrt. 

Soli nun aus der jeweiligen Kopiedatenbank und der Datenbank 
eine konsistente Datenbank erstellt werden, so gilt es, eine 
durch HinzufUgen, Entfernen oder Andern der Daten bzw. deren 
Struktur entstehende Inkonsistenz zu ermitteln und zu behe- 
ben . 

Unter einer Inkonsistenz ist im weiteren jede syntaktische 
Differenz innerhalb einer Kopiedatenbank bzw. der Datenbank, 
d.h. alle in den Kopiedatenbanken bzw. der Datenbank auftre- 
tenden Abweichungen zwischen den in der Datenbank bzw. einer, 
Kopiedatenbank enthaltenen Datenelementen, ihren Eigenschaf- 
ten sowie ihren Beziehungen zueinander zu verstehen. 

In [1] sind verschiedene Moglichkeiten aufgezeigt, urn eine 
solche Inkonsistenz zu beheben. 

Der Erfindung liegt das Problem zugrunde, ein weiteres Ver- 
fahren bzw.. eine weitere Vorrichtung zur Behebung von Inkon- 
sistenzen in einer Datenbankmenge anzugeben, mit dem eine 
moglichst Rechenzeit einsparende Behebung einer Inkonsistenz 
moglich wird. 



GR 98-p 2167 



3 

Das Problem wird durch das Verfahren, durch die Anordnung so- 
wie durch den Satz mehrerer Anordnungen mit den Merkmalen der 
unabhangigen Patentanspriiche gelost . 

Das Verfahren zur rechnergestiitzten Behebung mindestens einer 
Inkonsistenz in einer Datenbankmenge, die eine Datenbank so- 
wie mindestens eine Kopiedatenbank der Datenbank aufweist, 
welche Inkonsistenz durch eine Anderung in der Datenbank 
und/oder in der Kopiedatenbank entsteht, weist 'folgende 
Schritte auf: 

a) mindestens ein Teil der Operationen, die eine Inkonsistenz 
erzeugen konnen, ist definierten Konf likttypen zugeordnet, 

b) jedem Konflikttyp ist ein Entscheidungsset zugeordnet mit 
dem mogliche Entscheidungen angegeben werden, mit denen eine 
durch mindestens eine Operation des jeweiligen Konflikttyps 
erzeugte Inkonsistenz behoben werden kann, und 

c) die Inkonsistenz wird unter Verwendung des Entscheidungs- 
sets behoben. 

Die Anordnung zur Behebung mindestens einer Inkonsistenz in 
einer Datenbankmenge, die eine Datenbank sowie mindestens ei- 
ne Kopiedatenbank der Datenbank aufweist, welche Inkonsistenz 
durch Anderung der Daten in der Datenbank oder in der Kopie- 
datenbank entsteht/ weist mindestens einen Prozessor auf, der 
derart eingerichtet ist, daJi folgende Schritte durchfuhrbar 
sind: 

a) mindestens ein Teil der Operationen, die eine~~Inkonsistenz 
erzeugen konnen, ist definierten Konf likttypen zugeordnet, 

b) jedem Konflikttyp ist ein Entscheidungsset zugeordnet, mit 
dem mogliche Entscheidungen angegeben werden, mit denen eine 
durch eine Operation des jeweiligen Konflikttyps erzeugte In- 
konsistenz behoben werden kann. 
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c) die Inkonsistenz wird unter Verwendung des Entscheidungs- 
sets behoben. 

Der Satz mehrerer Anordnungen zur Behebung mindestens einer 
Inkonsistenz in einer Datenbankmenge, die eine Datenbank so- 
wie mindestens eine Kopiedatenbank der Datenbank aufweist, 
welche Inkonsistenz durch Anderung der Datenbank und/oder der 
Kopiedatenbank entsteht, weist mehrere Anordnungen auf, deren 
jede mindestens einen Prozessor auf weist, der derart einge- 
richtet ist, daJJ folgende Schritte durchfuhrbar sind: 

a) mindestens ein Teil der Operationen, die eine Inkonsi- 
stenz erzeugen konnen, ist definierten Konf likttypen zu- 
geordnet, 

b) jedem Konflikttyp ist ein Entscheidungsset zugeordnet, 
mit dem mogliche Entscheidungen angegeben werden, mit de- 
nen eine durch mindestens eine Operation des jeweiligen 
Konflikttyps erzeugte Inkonsistenz behoben werden kann, 

c) die Inkonsistenz wird unter Verwendung des Entscheidungs- 
sets behoben. 

Die Anordnungen sind miteinander koppelbar. 

Durch die Erfindung wird es moglich, eine Inkonsistenz in ei- 
ner komplexen Datenbank generisch zu losen. 

Bevorzugte Weiterbildungen der Erfindung ergeben sich aus deiS 
abhangigen Anspruchen. 

In einer bevorzugten Ausgestal tung werden mehrere Inkonsi- 
stenzen behoben. 

Bevorzugt wird in einer weiteren Ausgestaltung jedem Kon- 
flikttyp ein Entscheidungsset zugeordnet ist, mit dem mogli- 
che Entscheidungen angegeben werden, mit denen eine durch 
mehrere Operationen des jeweiligen Konflikttyps erzeugte In- 
konsistenz behoben" werden kann. 
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Ferner ist es in einer Weiterbildung vorgeseheri/ . daI5 die Da- 
tenbankmenge mehrere Kopiedatenbanken der Datenbank aufweist. 

Zur Vereinf achung und somit zur Rechenzeiteinsparung bei der 
Behebung einer Inkonsistenz ist es in einer Auisgestaltung der 
Erfindung vorgesehen, daJJ vor der Behebung jede Inkonsistenz 
und deren Abhangigkeiten voneinander erinittelt werden. 

Eine weitere Einsparung an benotigter Rechenzei't zur Behebung 
mehrerer Inkonsistenzen wird in einer weiteren Ausgestaltung 
dadurch erreicht, daJi das Entscheidungsset mindestens eines 
Konflikttyps wahrend der Behebung der Inkonsistenzen veran- 
dert wird. 

Dabei erfolgt die Anderung des jeweiligen Entscheidungssets 
bevorzugt abhangig von Abhangigkeiten der Inkonsistenzen. 

In einer bevorzugten Ausgestaltung ist es vorgesehen, nach 
einer vorgebbaren Anzahl behobener Inkonsistenzen die Daten- 
bankmenge auf weitere Inkonsistenzen und deren Abhangigkeit 
hin zu untersuchen. 

Die Datenbankmenge enthalt bevorzugt in einer Ausgestaltung 
eine ob j ektorientierte Datenbank. 

Das Verfahren kann im Rahmen der ob j ektorientierten Software- 
entwicklung oder auch im Rahmen der Erstellung eines struktu- 
rierten elektronischen Dokuments eingesetzt werden. 

Ein Ausf iihrungsbeispiel der Erfindung ist in den Figuren dar- 
gestellt und wird im weiteren naher erlautert. 

Es zeigen 

Figur 1 ein Ablauf diagramm, in dem die Verf ahrensschritte des 
Ausf iihrungsbeispiel s dargestellt sind; 
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Figur 2 eine Skizze, in der Rechner dargestellt sind, die 
tiber ein Kommunikationsnetz miteinander verbunden 
sind; 

5 Figur 3 eine Skizze einer Datenbankstruktur ; 

Figur 4 eine Tabellenilbersicht iiber mogliche Konflikte und 

Entscheidungssets mit Entscheidungsmoglichkeiten, um 
die jeweiligen Konflikte zu beheben. 

10 

FiSj^ zeigt einen ersten Rechner 200 mit einem Speicher 202 
und einem Prozessor 203, die jeweils Uber einen Bus 204 mit- 
einander und mit einer Eingangs-ZAusgangsschnittsteile 201 
verbunden sind. 

Uber die Eingangs-ZAusgangsschnittstelle 201 ist der erste 
Rechner 200 mit einem Bildschirm 205, einer Tastatur 206 so- 
wie einer Computermaus 207 verbunden. 

Ferner ist der erste Rechner 200 Uber ein Kommunikationsnetz 
2 60, in dem Beispiel ein ISDN-Netz (Integrated Services Digi- 
tal Network) mit weiteren Rechnern 210, 220, 230, 240 und 250 
verbunden. 

25 In dem ersten Rechner 200 ist eine Datenbank 208 gespeichert. 

Die weiteren Rechner 210, 220, 230, 240 und 250 weisen je- 
weils ebenfalls einen Prozessor 213, 223, 233, 243 und 253 
sowie jeweils einen Speicher 212, 222, 232, 242 und 252 auf. 
Jeweils der Prozessor 213, 223, 233, 243 und 253 und der 
Speicher 212, 222, 232, 242 und 252 sind uber jeweils einen 
Bus 214, 224, 234, 244 und 254 Uber eine Eingangs- 
/Ausgangsschnittstelle 211, 221, 231, 241 und 251 mit dem 
Kommunikationsnetz 260 verbunden. Ferner sind die weiteren 
Rechner 210, 220^ 230, 240 und 250 jeweils mit einem Bild- 
schirm 215; "225," 2""35," 245 und 255 sowie" einer Tastatur 216, 



20 



30 



35 
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226, 236, 246 und 256 sowie einer Compute rmaus 217, 227, 237, 
24 7 und 257 verbunden. 

Jewells eine Kopie der Datenbank 208, im weiteren als Kopie- 
datenbank 218, 228, 238, 248 und 258 bezeichnet, wird von dem 
ersten Rechner 200 an jeweils einen weiteren Rechner 210, 
220, 230, 240 und 250 ubermittelt und dort in dessen Speicher 
212, 222, 232, 242 und 252 gespeichert. 

Nach Obermittlung der Kopiedatenbanken 218, 228, 238, 248 und 
258 unterbrechen die Rechner 200, 210, 220, 230, 240 und 250 
die Kommunikation und es erfolgt jeweils unter den Rechnern 
Rechner 200, 210, 220, 230, 240 und 250 autark eine Anderung, 
d.h. Entfernung oder Hinzufugung von Daten oder Entfernung 
Oder Hinzufugung von Abhangigkeiten der Daten in einer Kopie- 
datenbank 218, 228, 238, 248 und 258 bzw, der Datenbank 208. 

Nach Wiederaufnahme der Kommunikation zwischen dem ersten 
Rechner 200 und den weiteren Rechnern 210, 220, 230, 240 und 
250 soil eine konsistente Datenbank aus der Datenbank 208 und 
den Kopiedatenbanken 218, 228, 238, 248 und 258 gebildet wer- 
den. 

Zu diesem Zweck ist es erf orderlich, jeweils vorgenommene An- 
derungen in der Datenbank 208 oder den Kopiedatenbanken fest- 
zustellen, um somit Inkonsistenzen zwischen den Kopiedaten- 
banken sowie der Datenbank 208 zu ermitteln, damit die Inkon- 
sistenzen behoben werden konnen, 

Unabhangig von der syntaktischen Struktur und der Abhangig- 
keiten der Datenelemente untereinander kann jedes Datenele- 
ment beliebig viele Eigenschaf ten besitzen. Jede Eigenschaft 
ist dabei von einem bestimmten Eigenschaf tstyp und wird durch 
einen aktuellen Wert reprasentiert . Fiir alle Eigenschaf ten 
wird bezuglich der Wertebereiche die Annahme getroffen, daB 
alle Werte nur aus Symbolen oder zusammengeset zten Symbolen 
einer ASCII-Tabelle bestehen durfen (Ziffern, Zahlen, Buch- 
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staben, Sonderzeichen, Zeichenketten) . Eine Folge solcher 
Zeichen und Symbole wird nachfolgend als Eintrag bezeichnet. 
Komplexere Eigenschaf ten werden bei der Anwendungsmodellie- 
rung durch Datenelemente und Beziehungen reprasentiert . 

Im weiteren werden drei Typen von Eigenschaf ten bei der syn- 
taktischen Analyse in Abhangigkeit der auf der Eigenschaft 
ausfuhrbaren Operationen unterschieden : 

• Einzelner Wert: 

Ein „Wert" als Eigenschaf tstyp beschreibt einen einzelnen 
Eintrag, wobei der Eintrag immer in seiner Gesamtheit gese- 
hen und auch so verandert wird. Eine Veranderung der Eigen 
schaft vom Typ „Wert" erfolgt dabei immer durch eine voll- 
kommene Ersetzung des Eintrages der Eigenschaft durch einen 
neuen Eintrag. 

• Aufzahlung: 

Eine „Aufzahlung« als Eigenschaf tstyp beschreibt eine Menge 
beliebiger Eintrage, wobei die Eintrage in keiner Relation 
zueinander stehen und ihrerseits einen einzelnen Wert, eine 
Aufzahlung oder eine geordnete Aufzahlung darstellen kon- 
nen. Die einzelnen Eintrage konnen dabei nur einzeln hinzu- 
gefiigt oder geloscht werden. Die Eindeutigkeit der Eintrage 
mufi bei eventueller Anforderung durch die Anwendung gewahr- 
leistet werden. Ein Beispiel fiir eine Datenstruktur, die 
diesen Eigenschaf tstyp reprasentiert ist eine Hash-Tabelle 
oder ein Array. 
' Geordnete Aufzahlung: 
Eigenschaften des Typs „geordnete Aufzahlung" beschreiben 
wie Eigenschaften des einfachen Auf zahlungstyps eine Menge 
beliebiger Eintrage. Die Eintrage stehen jedoch hier in ei- 
ner definierten Reihenfolge zueinander, die Uber einen In- 
dex fur jeden Eintrag festgelegt ist. Die Festlegung der 
Indices erfolgt relativ zum Beginn der Aufzahlung. Eine 
EinfUge-Operation mit einzelnen oder mehreren Eintragen be- 
- ziehtsichdeshalb immer auf einen Index. Eine Losch- 
Operation kann sich auf einen einzelnen Eintrag. mit nur ei- 
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nem Index oder auf eine Reihe auf einanderf olgender Eintrage 
und somit einem Anfangs- und einem Endindex beziehen. Das 
Kriterium der Reihenfolge wird von einem Anwendungsprograinin 
definiert und auch die Einhaltung der Reihenf olgekriterien 
5 wird von ihm iiberwacht. Ein Beispiel ftir diesen Eigen- 

schaftstyp ist eine indizierte Liste mit beliebigen Eintra- 
gen (z.B. Textdokument) , bei der jede Zeile oder jedes Zei- 
chen einem Eintrag entspricht. 

10 Unter einem Datenelement DE ist ein 4-Tupel zu verstehen, 
welches f olgendermaBen definiert ist: 

Datenelement 

Ein Datenelement DE ist ein 4-Tupel 
DE def^ (ID, inforaum, elementtyp, eigenschaften) ; 

• ID ist ein systemweit eineindeutiger Identifier . 

• inforaum € MIR; wobei MIR eine Menge aller Inf ormations- 
20 raume ist 

• elementtyp g ET; wobei ET eine Menge aller Datenelementty- 
pen ist 

• eigenschaften c { (name, eigenschaf tstyp, wert) : 

• name G MEN, wert ' g MEW, eigenschaf tstyp g MET}, 
wobei : 

MEN eine Menge aller Eigenschaf tsnamen ist und gilt: 

V i G {l,.*.,n}; V k g {1, ...,m}: name^ ^ namej^, 

30 MEW eine Menge aller Eigenschaf tswerte ist sowie 
MET eine Menge aller Eigenschaf tstypen 
{„wert'\ „auf zahlung'\ „geordnete aufzahlung"} ist. 

Ein Informationsraum wird im weiteren f olgendermaJien defi- 
35 niert: 

Informationsraum 
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Ein Informationsramn IR ist ein 3-Tupel 
IR def^ (ID, irname, eigentumer, daten) 



• ID ist ein systemweit eineindeutiger Identifier, 
wobei gilt: 

V i € (1, n); V k e (1, n) ; i ^ k:" 

IRi . ID ^ IRk. ID; 

wobei MIR eine Menge aller im System vorhandenen Irs ist 
und n deren Anzahl; 

• irname g MIRN 
wobei gilt: 

Vie (1, m) ; V k e (1, m) ; i ;t k: 

Iri. irname Irk. irname; 

wobei MIR die Menge aller im System vorhandenen Irs ist und 
m deren Anzahl; 

MIRN eine Menge aller moglichen Inf ormationsraiimnamen dar- 
stellt; 

• eigentiimer = Ni mit Ni g MN oder Ngi mit Ngi € MNG; 

• daten sind die durch eine Nutzergruppe zugreifbaren und dem 
IR zugeordneten Daten. 

Eine Beziehung zwischen den Datenelementen wird im weiteren 
folgendermaBen definiert: 

Beziehung zwischen Datenelementen 

Eine Beziehung BZ zwischen Datenelementen ist ein 3-Tupel 
BZ (beziehungstyp, name, datenelementl , datenelement2 ) 




• name e MBN; wobei MBN eine Menge aller Beziehungsnamen ist 

• beziehungstyp g MBT; wobei MBT eine Menge aller Beziehung- 
stypen 

{„ungerichtet^\ „logisch^\ ,,nachf olger", ,,subsup^M ist 

• datenelementl, 2 e MDE; wobei MDE eine Menge aller Da- 
tenelemente. ist: . _ _ _ _ 
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Urn Inkonsistenzen zu ermitteln, wird in jedem Rechner 200, 
210, 220, 230, 240 und 250 jeweils ein Protokoll Uber alle an 
der Datenbank bzw. der jeweiligen Kopiedatenbank vorgenomme- 
nen Operation mitgefuhrt und in Form einer Liste gespeichert. 

Die gespeicherte Liste wird im weiteren als Historie bezeich- 
net . 

Somit ist der Datenbank 208 sowie jeder Kopiedatenbank 218, 
298, 238, 248 und 258 jeweils eine Historie zugeordnet. 

Diese Situation ist in Fig. 3 dargestellt. Fig. 3 zeigt die Da- 
tenbank 301 mit Objekten 302, 303, 304 und 305 sowie einer 
Historie 306, die als Eintrage 307, 308, 309 Anderungsopera- 
tionen gespeichert hat, die seit Unterbrechung der Kommunika- 
tion mit den weiteren Rechnern 210, 220, 230, 240 und 250 von 
dem ersten Rechner 200 an der Datenbank 301 durchgef iihrt wur- 
den. Die Eintrage 307, 308, 309, werden ebenfalls in dem 
Speicher 202 des ersten Rechners 200 gespeichert. 

Einer ersten Kopiedatenbank 310 mit Objekten 311, 312, 313 
und 314 ist ebenfalls eine Historie 315 mit entsprechenden 
Anderungsoperationen 316, 317, 318 zugeordnet. Die Kopieda- 
tenbank 310 ist in dem weiteren Rechner 210 gespeichert. 

Eine zweite Kopiedatenbank 320 mit Objekten 321, 322, 323 und 
der ihr zugeordneten Historie 325 mit Anderungsoperationen 
326, 327, 328 ist in einem weiteren Rechner 220 gespeichert* 

Zur Bildung der konsistenten Datenbank, d.h. zur Reintegrati- 
on aller Kopiedatenbanken 218, 228, 238, 248 und 258 mit der 
Datenbank 208 werden die Historien 315, 325, ... zu dem er- 
sten Rechner 200 uber das Kommunikationsnetz 260 ubertragen 
und in dem Speicher 202 des ersten Rechners 200 gespeichert. 

Zu Beginn der Reintegration, der in Fig. 1 durch Schritt 101 
beschrieben ist, werden alle Historien der Kopiedatenbanken 
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zu dem ersten Rechner tlbertragen und dort gespeichert 
(Schritt 102) . 

In einem dritten Schritt (Schritt 103) werden alle im Rahmen 
5 der Reintegration zu beruc)csichtigende Historien 315, 325, 
. . . bestimmt . 

Im weiteren werden folgende Anderungsoperationen berUcksich- 
tigt, mit denen eindeutig die auf getretenen Inkbnsistenzen 
10 beschrieben werden. 

Im Rahmen dieses Ausfiihrungsbeispiels werden folgende neun 
Operationen als Anderungsoperationen beriicksichtigt, die im 
weiteren in Form eines Pseudo-Programmcodes beschrieben wer- 
1 5 den : 

1. Create Element: 

Create Element {R(IR), ID, Elementtyp) -^R(IR) 

20 createElement (ir, id, elementtyp) RETURN R(IR) 
BEGIN element := instantiate (elementtyp) 
element. el ementname:= id 
R(irj := insert (R(ir) .daten, element) 
R(ir):= add (R (ir) .historie, 
25 „createElement (id, elementtyp) ") 

return R(ir) 
END 



30 



35 




Diese Operation erzeugt ein Datenelement vom Datentyp ele- 
menttyp mit dem Identif ikator id in einer Kopiedatenbank 
R(ir) innerhalb eines Inf ormationsraums ir, auf den diese 
Operation angewendet wird. Dabei erhalten alle Eigenschaf ten 
des neu erzeugten Datenelementes einen vorgesetzten Initiali- 
sierungswert . Das neue Element wird nach dessen Initialisie- 
rung unter dem angegebenen Namen zu den Daten der Kopiedaten- 
bank R(irr und 'die ausgefUhrte Operation ohne den Informati- 
onsraum als Parameter in die der Kopiedatenbank zugeordneten 
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Historie R(ir) .historie hinzugefugt. Die Erzeugung des ein- 
eindeutigen Identifiers id ist dabei von der die Operation 
versendenden Anwendung vorzunehmen. 

2. DeleteElement : 

DeleteElement {R (IR) , ID) -> R(IR) 

deleteElement (ir, id) RETURN R(IR) 

BEGIN element:= select (R ( ir ) . daten, id) 

R(ir):= remove (R { ir) . daten, element) 

R(ir) ;= add(R(ir) . historie, 'MeleteElement (id) " ) 

return R(ir) 

END 

Diese Operation loscht ein Datenelement mit dem Namen id aus 
der Kopiedatenbank R(ir) des Inf ormationsraiims ir und 
schreibt die ausgefuhrte Operation in die der Kopiedatenbank 
zugeordneten Historie R(ir) .historie. Alle seit der Instanti- 
ierung des Datenelements veranderten Eigenschaf ten des Da- 
tenelementes gehen dabei mit verloren. Die das Element be- 
treffenden Beziehungen bleiben jedoch bestehen. Sollen diese 
ebenfalls geloscht werden, so ist das Anwendungsprogramm da- 
fiir verantwortlich. 

3. ChangeEigenschaf t : 

ChangeEigenschaft (R(IR) , ID, Eigenschaf tstyp, Wert) ->R{IR) 

changeEigenschaf t (ir, id, eigname, neuerWert) RETURN R(IR) 
BEGIN element := select (R (ir) . daten, id) 

eigenschaft := select (element . eigenschaf ten, 
eigname) ' - - , 

eigenschaf t .wert := neuerWert 

R(ir):= add (R (ir) .historie, „changeEigenschaf t 
(id, eigname, neuerWert)") 
return R(ir) 

END 
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Diese Operation setzt in der Kopiedatenbank R(ir) des Infor- 
mationsraums ir den Wert der Eigenschaft eigname des Da- 
tenelementes mit dem Identifier id auf den Wert neuerWert und 
schreibt die ausgefuhrte Operation in die der Kopiedatenbank 
zugeordneten Historie R(ir) .historie. 

4. ChangeEigenschaf tAdd: 

ChangeEigenschaf tAdd (R ( IR) , ID, Eigenschaf tstyp, Eintrag) -►R ( IR) 

changeEigenschaftAdd(ir, id, eigname, neuerEintrag) RETURN R(IR) 
BEGIN element := select (R (ir) . daten, id) 

eigenschaft := select (element . eigenschaf ten, 
eigname) 

add (eigenschaf t .wert, neuerEintrag) 
R(ir) := add(R(ir) .historie, 

„changeEigenschaftAdd (id, eigname, neuerEin- 
trag) ") 

return R(ir) 

END 



Diese Operation ist fUr Eigenschaf ten des Typs „auf zahlung« . 
Die Operation ftigt in der Kopiedatenbank R(ir) des Informati- 
onsraums ir im Wert der Eigenschaft eigname des Datenelemen- 
tes mit dem Identifier id am Ende der Aufzahlung einen neuen 
Eintrag neuerEintrag hinzu. Anschliefiend wird die ausgeftihrt 
Operation in die der Kopiedatenbank zugeordneten Historie 
R(ir) .historie gespeichert. 
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5 . ChangeEigenschaf tDel : 

ChangeEigenschaftDel (R{IR) , ID, Eigenschaf tstyp. Index, 

Eintrag) R(IR) 

ChangeEigenschaf tDel (ir, id, eigname, index, al terEintrag) 

RETURN R(IR) 
BEGIN element := select (R (ir ) . daten, id) 

eigenschaft := select (element . eigenschaf ten, 
eigname) 

del (eigenschaft .wert, alterEintrag) 
R(ir) := add (R ( ir ) .historie, 

^ChangeEigenschaftDel (id, eigname, index, al- 
terEintrag)^') 
return R(ir) 

END 

Diese Operation ist fur Eigenschaf ten des Typs „auf zahlung'' . 
Die Operation loscht in der Kopiedatenbank R(ir) des Informa- 
tionsraums ir im Wert der Eigenschaft eigname des Datenele- 
mentes mit dem Identifier id den ersten in der Aufzahlung 
auftretenden Eintrag alterEintrag. Danach wird die ausgefuhr- 
te Operation in der der Kopiedatenbank zugeordneten Historie 
R(ir) .historie gespeichert. 
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6 . ChangeEigenschaf tinsert ; 

ChangeEigenschaftInsert(R(IR) , id, Eigenschaf tstyp, Index, 

Anzahl, Eintrage) R(IR) 

5 changeEigenschaftlnsertdr, id, eigname, index, anzahl, 

neueEintrage) RETURN R(IR) 
BEGIN element := select (R (ir) .daten, id) 

eigenschaft := select (element . eigenschaf ten, 
eigname) 

for {i=0, i < anzahl, i++) { 

incr Index (eigenschaf t . wert . eintrage, ind >= in- 
dex) 

insert (eigenschaft. wert. index, neueEintra- 
ge. (anzahl -i) ) } 

R(ir) := add (R (ir) .historie, 

„changeEigenschaftInsert (id, eigname, index, an- 
zahl, neueEintrage)") 
return R(ir) 

END 



20 



25 



30 



Eine Eigenschaft, auf die diese Operation angewendet werden 
kann, ist vom Typ „geordnete auf zahlung" . Diese Operation 
fiigt in der Kopiedatenbank R(ir) des Inf ormationsraumes ir im 
Wert der Eigenschaft eigname des Datenelementes mit dem Iden- 
tifier id ab der Position Index in der geordneten Aufzahlung 
Eigenschaft. Wert eine Anzahl anzahl neuer Eintrage neueEin- 
trage. i ein. Alle Eintrage der geordneten Aufzahlung eigen- 
schaft. Wert mit einem gleichen oder grOBeren Index als index 
wird index urn den Wert anzahl erhSht. Danach wird die ausge- 
fUhrte operation in der der jeweilige Kopiedatenbank zugeord- 
neten Historie R(ir) .historie, gespeichert. 
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7 . ChangeEigenschaf tRemove : 

ChangeEigenschaftRemove(R(IR) , id, Eigenschaf tstyp, Index, 

Anzahl, Eintrage) R{IR) 

ChangeEigenschaf tRemove (ir, id, eigname, index, anzahl, 

alteEintrage) RETURN R(IR) 
BEGIN element := select (R ( ir ) . daten, id) 

eigenschaft := select (element . eigenschaf ten, 
eigname) 

for (i = 0, i < anzahl, i++) { 
remove (eigenschaf t .wert . index, alteEintra- 
ge . (i+1) ) 

decrlndex (eigenschaf t .wert . eintrage, ind > in- 
dex) } 

R(ir) := add (R (ir) . historic, 

„changeEigenschaf tRemove (id, eigname, index, an- 
zahl , alteEintrage ) ) 
return R(ir) 

END 

Eine Eigenschaft, auf die diese Operation angewendet werden 
kann, ist vom Typ „geordnete auf zahlung'^ , Diese Operation 
loscht in der Kopiedatenbank R(ir) des Inf ormationsraumes ir 
im Wert der Eigenschaft eigname des Datenelementes mit dem 
Identifier id ab der Position Index in der geordneten Aufzah- 
lung Eigenschaf t. Wert die Eintrage alteEintrage. Alle Eintra- 
ge mit groBerem Index als (index + anzahl) werden urn den Wert 
anzahl in ihrem Index verringert. Danach wird die ausgefiihrte 
Operation in der der jeweiligen Kopiedatenbank zugeordneten 
Historie R(ir) .historie gespeichert. 
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8. CreateBeziehung: 

Cr6ateBeziehung(R{iR) , Name, Beziehungstyp, IDl, ID2)^R(IR) 

CreateBeziehung (ir, name, beztyp, fromid, toid, toidir) 

RETURN R(IR) 
BEGIN beziehung := instantiate (beztyp) 
beziehung.name := name 
beziehung. datenelementl := fromid 
beziehung. datenelement2 := toid 
beziehung. datenelement2.ir := toidir 
R(ir) := insert (R (ir) .daten, beziehung) 
R{ir) := add (R (ir ) . historie, 

„createBeziehung (name, beztyp, fromid, toid, 

toidir)") 

return R(ir) 

END 

Diese Operation erzeugt eine Beziehung des Typs beztyp zwi- 
schen den Datenelementen mit den Identifiern fromid and toid 
unter dem Namen name und fiigt die neue Beziehung zu den Daten 
der Kopiedatenbank R(ir) des Inf ormationsraums ir hinzu. Da- 
nach wird die ausgeftihrte Operation in der der Kopiedatenbank 
zugeordneten Historie R(ir) .historie gespeichert. Es wird fiir 
alle Beziehungen angenommen, da& es pro vergebenen Bezie- 
hungsnamen nur eine einzige Beziehung des gleichen Typs zwi- 
schen zwei Datenelementen gibt . Sind mehrere Beziehungen des 
gleichen Typs unter dem gleichen Namen zwischen zwei Da- 
tenelementen notwendig, so sind auch fUr Beziehungen Identi- 
fier einzufUhren. Ftir die Mehrzahl der Anwendungen reicht die 
getroffene Annahme jedoch aus. Die Angabe des Inf ormations- 
raumes des Zieldatenelementes ist nur im Falle einer logisch 
extern gerichteten Beziehung notwendig. 
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9 • DeleteBeziehung : 

DeleteBeziehung{R (IR) , Name, Beziehungstyp, IDl, ID2)->R{IR) 

deleteBeziehung (ir, name, beztyp, fromid, toid.toidir) 

RETURN R(IR) 

BEGIN beziehung := select (R (ir ) . daten, name, beztyp, 

fromid, toid) 
R(ir) := remove (R ( ir ) . daten, beziehung) 
R(ir) := add (R ( ir ) . historie, 
„deleteBeziehung (name, beztyp, fromid, 
toid.toidir)"^) 
return R(ir) 

END 

Diese Operation loscht eine Beziehung des Typs beztyp zwi- 
schen den Datenelementen mit den Identifiern fromid and toid 
unter dem Name name aus der Kopiedatenbank R(ir) des Informa- 
tionsraumes ir. Danach wird die ausgefuhrte Operation in der 
der Kopiedatenbank zugeordneten Historie R(ir) .historie ge- 
speichert. Die Angabe des Inf ormationsraums des Zieldatenele- 
ments ist nur fur die Beziehungen vom Typ logisch extern ge- 
richtet notwendig. 

In einem weiteren Schritt werden alle Konflikte, Abhangigkei- 
ten, Anomalien, Pseudo-Anomalien, sowie Einschrankungen durch 
Abhangigkeiten erkannt (Schritt 103) . 

Unter einem Konflikt ist die kleinste entscheidbare Menge von 
syntaktisch nur einseitig auftretenden Operationen, die eine 
Inkonsistenz eindeutig beschreiben und einem Nutzer oder dem 
System sinnvoll prasentiert und von ihm behoben (entschieden) 
werden konnen, zu verstehen. 

Jeder Konflikt ist als Ganzes zu erkennen und durch eine ein- 
zige Entscheidung wahrend der Reintegration losbar. 
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MGgliche Konflikte warden anschliefiend abhangig von der Da- 
tenstruktur und den in der Historie vorkommenden Operationen 
def iniert . 

Es werden harmlose Konflikte und kritische Konflikte unter- 
schieden. 

Harmlose Konflikte (HK) beinhalten nur Operationen, die Ver- 
anderungen auf einer Kopiedatenbank beschreiberi. Es gibt in 
diesem Fall somit nur einen Nutzer, der eine Anderung an dem 
Teil der Datenstruktur bzw. der Kopiedatenbank oder auch der 
Datenbank selbst wunscht und durchftlhrt. Die vorgenominenen 
Operationen ergSnzen sich somit. Abhangig davon, welcher Ko- 
piedatenbank die Operation bzw. Operationen zuzuordnen sind, 
konnen allgemein bei Vorhandensein der Kopiedatenbanken von 
Benutzern A und B harmlose Konflikte mit Operationen auf der 
Kopiedatenbank eines ersten Benutzers A als HKA und harmlose 
Konflikte mit Operationen auf der Kopiedatenbank eines zwei- 
ten Benutzers B als HKB bezeichnet werden. 

Kritische Konflikte (KK) dagegen enthalten beidseitige Ande- 
rungen zum gleichen Teil der Datenstruktur und stellen kon- 
trare Ansichten der Benutzer uber den letztendlichen Zustand 
bestimmter Daten innerhalb der Datenbank bzw. Kopiedatenban- 
ken dar. Dabei kann ein kritischer Konflikt auch durch unter 
schiedliche Operationen auf zwei Kopiedatenbanken definiert 
werden. In diesen Fallen wird zwischen einem kritischen Kon- 
flikt KKA und einem kritischen Konflikt KKB unterschieden. 

Formal wird ein Konflikt wie folgt definiert: 
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Konflikt: 

Ein Konflikt K zweier Historian EPiA und EHB und einer gemein- 
samen Historie GH ist ein 6-Tupel 

K(EHA, EHB, GH) def 

(id, ktyp, operationenEHA, operationenEHB, 
operationenGH, entscheidungseinschr ) ; 

• id ist ein systemweit eineindeutiger Identifier (siehe auch 
die Definition eines Datenelements) 

• ktyp € {HKIA, HKllA, HKIB, HKllB, KKl, KK2, 

KK3A, KK3B, KK4, KK5A, KK5B, KK6, KK7, KK8A, KK8B} 

• operationenEHA e EHA. operationen; 

• operationenEHB € EHB . operationen; 

• operationenGH € GH* operationen; 

• entscheidungseinschr e MENTktyp; wobei MENTktyp eine Menge 
aller moglichen Entscheidungen fiir einen Konflikt vom Typ 
ktyp ist. 

Die Konflikte sind in Fig. 4 dargestellt. 

1. Erster Harmloser Konflikt HKl : 

HKl = (createElement/ — ) 

Es liegt eine Erzeugungsoperation eines Datenelements 
createElement ( id, elementtyp) in nur einer Historie vor» 
HKIA = createElement (id, elementtyp) e EHA v 
HKIB = createElement (id, elementtyp) e EHB. 

2. Zweiter Harmloser Konflikt HK2 : 

HK2 = (deleteElement/ — ) 

Es liegt eine Loschoperation zu einem Datenelement 
deleteelement (id, elementtyp) in nur einer Historie vor. 
HK2A = deleteElement (id, elementtyp) € EHA v 
HK2B = deleteElement (id, elementtyp) e EHB. 
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3. Dritter Harmloser Konflikt HK3 : 

HK3 = (createBeziehung/ — ) 

Es liegt eine Erzeugungsoperation einer Beziehung 
createBeziehung (beztyp, bname, idl, id2) in nur einer Histo- 
rie vor. 

HK3A = createBeziehung (beztyp, bname, idl, id2) e EHA v 
HK3B = createBeziehung (beztyp, bname, idl, id2) e EHB. 

4. Vierter Harmloser Konflikt HK4 : 

HK4 = {deleteBeziehung/ — ) . 
Es liegt eine Loschoperation einer Beziehung 

deleteBeziehung {beztyp, bname, idl, id2) in nur einer Histo- 
rie vor. 

HK4A = deleteBeziehung (beztyp,bname, idl, id2) € EHA v 
HK4B = deleteBeziehung (beztyp,bname, idl, id2) g EHB. 

5. Funfter Harmloser Konflikt HK5 : 

HK5 = (deleteBeziehungl2, createBeziehung 13/ — ) 
Es liegt eine Loschoperation einer Beziehung 
deleteBeziehung (beztyp, bname idl, id2) und eine nachfolgende 
Erzeugungsoperation der Beziehung 

createBeziehung (beztyp, bname, idl, id3) vom gleichen Quell- 
datenelement zu einem anderen Zieldatenelement nur einer Hi- 
storie vor. 

HK5A = [deleteBeziehung (beztyp, bname, idl, id2) , 

createBeziehung (beztyp, bname, idl, id3) ] € EHA v 

HK5B = [deleteBeziehung (beztyp, bname, idl, id2) , 

createBeziehung (beztyp, bname, idl, id3) ] e EHB. 

6. Sechster Harmloser Konflikt HK6: 

HK6 = (changeEigenschaf t/ — ) 
Es liegt eine Anderungsoperation 

changeEigenschaf t (id, name, wertneu, wertalt) zu einer Eigen- 
schaft vom Typ „Werf in nur einer Historie vor. 
HK6A = ChangeEigenschaf t (id, name, wertl, wertO) € EHA v 
HK6B = ChangeEigenschaf t (id, name, wertl, wertO) € EHB. 
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7. Siebter Harmloser Konflikt HK7 : 

HK7 = (n X changeEigenschaf tAdd/ — ) 

Es liegen n (n ist Element der natlirlichen Zahlen und n > 0) 
Einfiigeoperationen changeEigenschaf tAdd { id, name, eintrag) 
5 mit dem gleichen Eintrag eintrag zur gleichen Eigenschaft vom 
Typ ,,auf zahlung^' eines Datenelements in einer Historie vor, 
wobei es in einer anderen Historie keine Loschoperation mit 
dem gleichen Eintrag zur gleichen Eigenschaft des Datenele- 
ments gibt. Die beschriebene Inkonsistenz besteht darin, dafl 
10 in der Kopiedatenbank mit den Erzeugungsoperationen in der 
der Kopiedatenbank zugeordneten Historie n Eintrage der Art 
eintrag mehr vorhanden sind als in der jeweils anderen Kopie- 
datenbank. 

HK7A = n mal changeEigenschaf tAdd (id, name, eintrag) € EHA v 
15 HK7B = n mal changeEigenschaf tAdd ( id, name, eintrag) e EHB. 

8. Achter Harmloser Konflikt HK8 : 

HK8 = (n X changeEigenschaf tDel/ ) 

Es liegen n (n ist Element der naturlichen Zahlen) Loschope- 
20 rationen changeEigenschaf tDel ( id, name, eintrag) mit dem 
gleichen Eintrag eintrag zu einer Eigenschaft vom Typ 
„aufzahlung" eines Datenelements in einer Historie vor, wobei 
in einer anderen Historie keine Einf ugeoperation mit dem 
gleichen Eintrag zu der Eigenschaft des Datenelements vor- 
5 liegt. Die beschriebene Inkonsistenz besteht darin, daB in 
der Kopiedatenbank, in dessen Historie die Loschoperationen 
stehen, die n Eintrage der Art eintrag weniger vorhanden 
sind, als in der jeweils anderen Kopiedatenbank. 
HK8A = n mal changeEigenschaf tDel ( id, name, eintrag) e EHA v 
30 HK8B = n mal changeEigenschaf tDel ( id, name, eintrag) g EHB. 

9. Neunter Harmloser Konflikt HK9: 

HK9 = (changeEigenschaf tinsert/ — ) 
Es liegt eine Einf Ugeoperation 
35 changeEigenschaf tinsert (id, name, indexl/ 1, eintragl) zu ei- 
nem Index mit einem einzelnen Eintrag zu einer Eigenschaft 
vom Typ „geordnete aufzahlung" eines Datenelementes in nur 
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11. Elfter Harmloser Konflikt HKll: 

HKll = (changeEigenschaftRemove, changeEingenschaf tinsert/ — ) 
Es liegt eine Loschoperation 

ChangeEigenschaftRemove (id, name, indexl, 1, eintragl) zu ei- 
nem Index index mit einem einzelnen Eintrag zu einer Eigen- 
schaft vom Typ ^geordnete aufzahlung" eines Datenelements und 
eine nachfolgende Erzeugungsoperation 

changeEigenschaftlnsert (id, name, indexl, 1, eintrag2) eines 
Eintrages zum gleichen Index der gleichen Eigerischaft des 
gleichen Datenelements in nur einer Historie vor. 
HKllA = [changeEigenschaftlRemove (id, name, index, 1, eintragl), 
changeEigenschaftllnsert (id,name, index, 1, eintrag2) ] 
€ EHA V 

HKllB = [ChangeEigenschaftlRemove (id, name, index, 1, eintragl) , 
ChangeEigenschaftllnsert (id, name, index, 1, eintrag2) ] 
€ EHB. 



Im weiteren wird eine Ubersicht uber kritische Konflikte (KK) 
d.h. Operationen in mehreren Historien, gegeben: 

1, Erster Kritischer Konflikt KKl : 

KKl = (createBeziehungl2/ createBeziehungl3 ) 
Es liegt eine Erzeugung einer Beziehung 

createBeziehung{beztyp, bname, idl, id2) in einer Historie 
vor, wobei in einer anderen Historie eine Erzeugung 
createBeziehung(beztyp, bname, idl, id3) der gleichen Bezie- 
hung (beztyp, bname) vom gleichen Quelldatenelement ausgehend 
aber zu einem anderen Zieldatenelement existiert. 
KKl = createBeziehung (beztyp, bname, idl, id2) e EHA a 
createBeziehung (beztyp, bname, idl, id3) g EHB, 

2. Zweiter Kritischer Konflikt KK2 : 

KK2 = (deleteBeziehungl2, createBeziehunglS / 

deleteBeziehungl2, createBeziehungl4 ) 
Die unterschiedliche Anderung einer Beziehung kann in den Hi- 
storien wie "der erste kritisch"e' Konflikt KKl erkannt werden/ 
Zusatzlich liegt jedoch in einer gemeinsamen Historie GH eine 



• 
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einer Historie vor, wobei in einer anderen Historie keine 
Einf iigeoperationen itiit einem anderen Eintrag zu nachrechenb 
rem gleichen Index zu der gleichen Eigenschaft des Datenele 
mentes vorliegt, 

HK9A = changeEigenschaf tinsert {id, name, index, 1, eintrag) 
G EHA V 

HK9B = changeEigenschaf tinsert (id, name, index, 1, eintrag) 
e EHB . 

10. Zehnter Harmloser Konflikt HKIO: 

HKIO = (changeEigenschaf tRemove/ — ) 
Es liegt eine Loschoperation 

ChangeEigenschaf tRemove (id, name, indexl, 1, eintragl) zu e 
nem Index mit einem einzelnen Eintrag zu einer Eigenschaft 
vom Typ „geordnete aufzahlung'' eines Datenelements in nur e 
ner Historie vor. 

HKIOA = changeEigenschaf tIRemove (id, name, index, 1, eintrag) 
e EHA V 

HKIOB = changeEigenschaf tIRemove (id, name, index, 1, eintrag) 
e EHB. 
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Loschung deleteBeziehung (beztyp, bname, idl, id2) der gemein- 
samen Beziehung (bname, beztyp) vom gleichen Quelldatenele- 
ment, aber zu einem anderen Zieldatenelement vor, 
KK2 = deleteBeziehung (beztyp, bname, idl, id2) € GH a 
createBeziehung (beztyp, bname, idl, id3) € EHA a 
createBeziehung (beztyp, bname, idl, id4) g EHB. 

3. Dritter Kritischer Konflikt KK3: 

KK3 = (deleteBeziehungl2, createBeziehungl3/ 

deleteBeziehungl2) 
Die einseitige Veranderung und anderseitige Loschung einer 
Beziehung kann in den Historien wie der dritte harmlose Kon- 
flikt HK3 durch eine Operation 

createBeziehung (beztyp, bname, idl, id3) erkannt werden. 
Zusatzlich liegt jedoch in der gemeinsamen Historie eine 
Loschung 

deleteBeziehung (beztyp, bname, idl, id2) der gemeinsamen Be- 
ziehung (bname, beztyp) vom gleichen Quelldatenelement , aber 
zum letzten gemeinsamen Zieldatenelement vor. 
KK3A = deleteBeziehung (beztyp, bname, idl, id2) e GH a 
createBeziehung (beztyp, bname, idl, id3) g EHA; 
KK3B = deleteBeziehung (beztyp, bname, idl, id2) g GH a 



4, Vierter Kritischer Konflikt KK4 : 

KK4 = (changeEigenschaf t/ changeEigenschaf t ) 
Es liegt eine Anderungsoperation 

ChangeEigenschaf t (id, name, wertneul, wertalt) zu einer Ei- 
genschaft des Typs ,,wert^^ eines Datenelements in einer Histo- 
rie vor, wobei in einer anderen Historie zur gleichen Eigen- 
schaft des Datenelements eine andere Anderungsoperation exi- 
stiert. 

KK4 = ChangeEigenschaf t (id, name, wertneul, wertalt) g EHA a 
changeEigenschaf t (id,name,wertneu2, wertalt) g EHB. 



createBeziehung (beztyp, bname, idl, id3) 



G EHB. 



GR 98 P 2167 



27 

5. Fiinfter Kritischer Konflikt KK5 : 

KK5 = (n changeEigenschaf tAdd/ m changeEigenschaf tDel) 
Es liegen n (n ist Element der natiirlichen Zahlen) gleiche 
Operationen der Art 
5 changeEigenschaf tAdd (id, name, eintrag) mit dem gleichen Ein 
trag zu einer Eigenschaft vom Typ ,,auf zahlung^' eines Da- 
tenelements in einer Historie vor, wobei in einer anderen Hi 
storie m (m ist Element der natiirlichen Zahlen) gleiche Ope- 
rationen der Art 

0 changeEigenschaf tDel ( id, name, eintrag) mit dem gleichen Ein 
trag zur gleichen Eigenschaft des Datenelements vorliegen. 
Die beschriebene Inkonsistenz besteht darin, dali in der Ko- 
piedatenbank mit den Erzeugungsoperationen in der der Kopie- 
datenbank zugeordneten Historie n + m gleiche Eintrage ein- 

5 trag mehr vorhanden sind als in der anderen Kopiedatenbank. 
Um eine exakte Aussage tiber das Auftreten der Operationen 
treffen zu konnen, wird bei dem flinften kritischen Konflikt 
KK5 zwischen einem fiinften kritischen Konflikt erster Art 
KK5A und einem fiinften kritischen Konflikt zweiter Art KK5B 

0 unterschieden. Die Zuordnung erfolgt dabei iiber die Erzeu- 
gungsoperationen . 

KK5A = (n changeEigenschaf tAdd (id, name, eintrag) e EHA a 
m changeEigenschaf tDel ( id, name, eintrag) e EHB v 
KK5B = (m changeEigenschaf tDel (id, name, eintrag) e EHA; 
5 n changeEigenschaf tAdd (id, name, eintrag) e EHB. 
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6. Sechster Kritischer Konflikt KK6: 

KK6 = (changeEigenschaftlnsert / changeEigenschaf tinsert ) 
Es liegt eine EinfUgeoperation 

ChangeEigenschaftlnsert (id, name, indexl, 1, eintragl) zu ei 
nem Index mit einem einzelnen Eintrag zu einer Eigenschaft 
vom Typ „geordnete aufzahlung" eines Datenelements in einer 
Historie vor, wobei in einer anderen Historie eine EinfUge- 
operation mit einem anderen Eintrag zum nachrechenbar glei- 
chen Index der Eigenschaft des Datenelements vorliegt. 

KK6 = ChangeEigenschaftlnsert (id, name, indexl, 1, eintragl) 
e EHA A 

ChangeEigenschaftlnsert (id, name, index2, 1, eintrag2) 
G EHB. 

7. Siebter Kritischer Konflikt KK7: 

KK7 = (changeEigReraove, changeEiglnsert / 

changeEigRemove, changeEiglnsert) 
Die beidseitig unterschiedliche Anderung eines einzelnen Ein- 
trages an einem gemeinsamen Index index zu einer Eigenschaft 
vom Typ „geordnete aufzahlung" eines Datenelementes ist in 
den Historien wie der sechste kritische Konflikt KK6 erkenn- 
bar. Zusatzlich liegt jedoch in der gemeinsamen Historie eine 
ChangeEigenschaf tRemove (id, name, indexl, 1, eintragl) - 
Operation des letzten gemeinsamen Eintrages am nachrechenbar 
gleichen Index vor. 

KK7 = ChangeEigenschaf tRemove (id, name, indexl, 1, eintragl) 
e GH A 

ChangeEigenschaftlnsert ( id, name, index2 , 1 , eintrag2 ) 
G EHA A 

ChangeEigenschaftlnsert (id, name, index3, 1, eintragS) 
e EHB. 
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8, Achter Kritischer Konflikt KK8 : 

KK8 = {changeEigRemove, changeEiglnsert / changeEi gRemove) 
Die einseitige Anderung und anderseitige Loschung eines ein- 
zelnen Eintrages an einem gercieinsamen Index index zu einer 
Eigenschaft vom Typ „geordnete aufzahlung^' eines Datenele- 
ments in den Historien ist wie ein zehnter harialoser Konflikt 
HKIO erkennbar. Zusatzlich liegt jedoch in der gemeinsamen 
Historie eine 

changeEigenschaf tRemove (id, name, indexl, 1, eihtragl)- 
Operation des letzten gemeinsamen Eintrages am nachrechenbar 
gleichen Index vor. 

KK8A = changeEigenschaf tRemove (id, name, indexl, 1, eintragl) 
€ GH A 

changeEigenschaf tinsert (id, name, index2, l,eintrag2) 
€ EHA; 

KK8B = changeEigenschaf tRemove ( id, name, indexl , 1 , eintragl ) 
G GH A 

changeEigenschaf tinsert (id, name, index2, 1, eintrag2) 
G EHB. 

Die in den Historien gespeicherten Operationen beschreiben 
die autonom veranderten Datenbereiche direkt und werden zur 
Beschreibung sowie zur im weiteren beschriebenen Behebung der 
Inkonsistenzen verwendet. 

Zur Erkennung der Inkonsistenzen werden jeweils zwei Histori- 
en miteinander verglichen. 

Die Erkennung der Inkonsistenzen erfolgt zu Beginn des Ver- 
fahrens, vor der eigentlichen Reintegration, 

Die Suche nach den vorhandenen Inkonsistenzen in den Kopieda- 
tenbanken durch die Suche nach Konf liktoperationen erfolgt in 
den im weiteren beschriebenen drei Schritten. 

• In einem ersten Schritt werden die zwei miteinander zu ver- 
gleichenden Historien von den Kopiedatenbanken bzw. der Da- 



GR 98 P 2167 



30 

tenbank durchlauf en, die miteinander abgeglichen werden 
sollen. Alle Operationen der Historien werden auf jeder 
Seite getrennt jeweils einer der oben beschriebenen neuen 
Operationsmengen ( createElement-Operationen, deleteElement 
Operationen, createBeziehung-Operationen, delete-Beziehung 
Operationen, changeEigenschaf t-Operationen, changeEigen- 
schaf tAdd-Operationen, changeEigenschaf tDel-Operationen, 
changeEigenschaf tInsert-Operationen und 
ChangeEigenschaf tRemove-Operationen) zugeordriet . 

• In einem zweiten Schritt wird flir jeden oben beschriebenen 
Konflikttyp HKIA, HKllA, HKIB, HKllB, KKl, KK2, 

KK3A, KK3B, KK4, KK5A, KK5B, KK6, KK7, KK8A, KK8B jeweils 
ein Konfliktregister KR angelegt. Dabei wird gewahrleistet , 
dafi alle Konflikte, bei denen Operationen aus beiden Histo- 
rien zum jeweiligen Konflikt beitragen, nicht doppelt er- 
kannt und doppelt in dem jeweiligen Konfliktregister KR ab- 
gelegt werden. Danach werden entsprechend den Definitionen 
der Konf likttypen, wie oben beschrieben, beginnend mit dem 
ersten harmlosen Konflikt HKIA in der Historie des ersten 
Benutzers A, die gerade gebildeten Operationsmengen durch- 
sucht. Wurde ein Konflikt ermittelt, so wird der Konflikt 
im Konfliktregister KR des entsprechenden Konflikttyps ab- 
gelegt, beispielsweise wird der erste harmlose Konflikt HKl 
in der Kopiedatenbank des ersten Benutzers A in einem Kon- 
fliktregister KR_HK1A abgelegt. 

• 1st die Suche und Speicherung der Konflikte erfolgt, werden 
in einem dritten Schritt die zu Beginn erstellten Operati- 
onsmengen wieder geloscht. Die nachfolgende Behebung der 
Inkonsistenzen beruht auf den in den Konf liktregistern KR 
abgelegten Konflikten und deren Operationen, 

Ein Konfliktregister KR ist wie folgt definiert: 
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Konfliktregister KR: 

Ein Konf liktregister KR zweier Historien EHA und EHB und ei- 
ner geme ins amen Historie GH ist ein 2-Tupel 

5 KR(EHa, EHb, GH) def^ (krtyp, konfliktids) 

• krtyp G {KA_HK1A, KA_HK11A, KA_HK1B, KA_HK11B, 

KA_KK1, KA_KK2/ KA_KK3A, KA_KK3B, KA_KK4, KA_KK5A, KA_KK5B, 
KA__KK6, KA_KK7, KA_KK8A, KA_KK8B} 
10 • konfliktids sind Identifier aller dem Konf liktregister KR 
zugeordneten Konflikte K(EPiA, EHB, GH) , wobei K.typ dem je- 
weiligen Konf liktarraytyp KR. krtyp zuzuordnen ist. 

Eine Anomalie liegt dann vor, wenn zwei Datenelemente in bei- 
15 den Kopiedatenbanken vor und nach der Teilung existieren und 
diese nach der Teilung durch eine gerichtete Beziehung vom 
gleichen Typ beztyp und mit gleichem Namen bname, jedoch mit 
vertauschtem Quelldatenelement und Zieldatenelement verbunden 
sind. Wahrend der Reintegration muJJ mindestens eine dieser 
2 0 Beziehungen abgelehnt oder mussen beide verandert werden. 

Unter einer gerichteten Beziehung ist eine Beziehung zu ver- 
stehen, die von einem Zieldatenelement zu einem Quellda- 
tenelement gerichtet ist. 

5 

Eine Anomalie ist wie folgt definiert: 
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Anomalie: 

Eine Anomalie AM zweier Konf likte Kl (EHA, EHB, GH) und 
Kl (EHA, EHB, GH) ist ein 4-Tupel 

AM(K1, K2) def^ (id, amtyp, kidl, kid2) 

• id ist ein systemweit eineindeutiger Identifier (siehe auch 
Definition eines Datenelementes ) 

• amtyp e {AnomalielA, Anomaliel6AB } 

• kidl = Kl.id 

• Kid2 = K2.id. 

Ein Anomalieregister AMR zweier Historien ist wie folgt defi 
niert : 

Anomalieregister AMR: 

Ein Anomalieregister AMR zweier Historien EHA und EHB und ei- 
ner gemeinsamen Historie GH ist ein 1-Tupel 

AMR (EPIA, EHB, GH) ^ { anomalieids ) 

• anomalieids sind die Identifier aller Anomalien der Histo- 
rien EHA und EHB und der gemeinsamen Historie GH. 

Pseudo-Anomalien beschreiben Situationen, in denen das Ent- 
stehen einer Anomalie aus vorliegenden Konflikten nur durch 
eine gezielte Minimierung der Entscheidungsmoglichkeiten der 
Konf likte vermieden werden kann. 

Eine Pseudo-Anomalie ist, wie im folgenden dargestellt, defi- 
niert: 
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Pseudo-Anomalie PAM: 

Eine Pseudo-Anomalie PAM zweier Konf likte Kl (EHA, EHB, GH) 
und KKEHA, EHB, GH) ist ein 4-Tupel 

5 PAM(K1, K2) def (id, pamtyp, kidl, kid2) 

• id ist ein systemweit eineindeutiger Identifier (siehe auch 
Definition eines Datenelementes ) 

• pamtyp e { Pseudo-AnomalielA, Pseudo-Anomalie32AB} 
10 • kidl = Kl.id 

• kid2 = K2.id, 

Ein Pseudo-Anomalieregister PAMR ist wie folgt definiert: 

15 Pseudo-Anomalieregister PAMR: 

Ein Pseudo-Anomalieregister PAMR zweier Historien EHA und EHB 
und einer gemeinsamen Historie GH ist ein 1-Tupel 

PAMR (EHA, EHB, GH) def ( Pseudo-Anomalieids ) 

20 

• Pseudo-Anomalieids sind die Identifier aller Pseudo- 
Anomalien der Historien EHA und EHB sowie der gemeinsamen 
Historie GH. 

Nach Ermittlung der Konf likte wird jeder ermittelte Konflikt 
jeweils durch eine einzelne Entscheidung gelost. Der Kon- 
f liktlosungsprozeB besteht somit aus einer Sequenz von Kon- 
flikt losungsentscheidungen, 

30 Die Konf liktlosung ist in Fig, 1 mit Schritt 104 bezeichnet. 

Grundsatzlich gibt es verschiedene Entscheidungsmoglichkei- 
ten: 

a)Annahme der Konf liktoperation (en) 
35 b)Ablehnung der Konf liktoperation (en) 

c)Teilweise Annahme, teilweise Ablehnung der Konf liktoperati- 
on(en) 
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d)Ablehnung der Konf liktoperation (en) , Anname neuer erzeugter 
Operation (en) . 

Den einzelnen Konf likttypen wird ein Entscheidungsset ES zu- 
geordnet, wobei der Entscheidungsset ES mogliche Entscheidun- 
gen enthalt, mit denen eine durch eine Operation des jeweili- 
gen Konf likttyps, dem jeweils ein Entscheidungsset ES zuge- 
ordnet ist, erzeugte Inkonsistenz behoben werden kann. 

In der Fig. 4 ist eine Zusammenstellung aller Entscheidungs- 
sets, die jeweils einem Konflikt zugeordnet sind, darge- 
stellt. 

Es wird jeweils in einer Zeile der in Fig. 4 dargestellten Ta- 
belle eine mogliche EntscheidungsmOglichkeit El, E2, E3a, 
E3b, E4, E5a, E5b, E6 dargestellt. 

Mit einem x in einem Feld ist jeweils bezeichnet, dafi der je- 
weils in der Spalte aufgefUhrte Konflikt durch eine Entschei- 
dungsmoglichkeit, die in der jeweiligen Zeile dargestellt 
ist, gelost werden kann. 

Im weiteren wird eine Obersicht Uber die moglichen Entschei- 
dungsmSglichkeiten gegeben: 

Eine erste Entscheidungsm5glichkeit El beschreibt die Annahme 
einer Konf liktoperation oder mehrerer Konf liktoperationen . 

Eine Konf liktoperation beschreibt alle zu einem Konflikt ge- 
horenden Datenoperationen. Unter Annahme wird verstanden, daB 
die Konfliktoperationen in der Kopiedatenbank, in der sie 
noch nicht vorgenommen worden sind, ausgefiihrt werden. 

Eine zweite Entscheidungsmoglichkeit E2 beschreibt die Ableh- 
nung einer Konf liktoperation oder mehrerer Konfliktoperatio- 
nen. 
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Eine dritte Entscheidungsmoglichkeit E3 beschreibt die Annah- 
me einer oder mehrerer Konf liktoperationen (en) in einer Ko- 
piedatenbank und die Ablehnung der Konf liktoperation (en) in 
der anderen Kopiedatenbank. 

5 

Fur die dritte Entscheidungsmoglichkeit E3 ist eine Detai- 
lentscheidung vorgesehen, die definiert, welche der in den 
Historien verschiedener Kopiedatenbanken der Benutzer A und B 
vorliegenden Konf liktoperationen angenommen und" welche abge- 
10 lehnt werden sollen. 

Diese Entscheidungsmoglichkeiten werden als erster Teil E3a 
der dritten Entscheidungsmoglichkeit E3 und zweiter Teil E3b 
der dritten Entscheidungsmoglichkeit E3 bezeichnet. Der erste 
15 Teil E3a der dritten Entscheidungsmoglichkeit E3 beschreibt 
die Annahme der Konf liktoperation (en) in der Kopiedatenbank 
des ersten Benutzers A und die Ablehnung der Konf liktoperati- 
on (en) in der Kopiedatenbank des zweiten Benutzers B. Der 
zweite Teil E3b der dritten Entscheidungsmoglichkeit E3 be- 
20 schreibt die Annahme der Konf liktoperation (en) der Kopieda- 
tenbank des zweiten Benutzers B und die Ablehnung der Kon- 
f liktoperation (en) der Kopiedatenbank des ersten Benutzers A. 

Wie in Fig. 4 dargestellt, beschreibt ein erster Entschei- 
5 dungsset ESI, der dem ersten harmlosen Konflikt HKl zugeord- 
net ist, die erste Entscheidungsmoglichkeit El sowie die 
zweite Entscheidungsmoglichkeit E2 zur Erhebung des ersten 
harmlosen Konflikts HKl. 

30 Ein zweiter Entscheidungsset ES2 ist dem zweiten harmlosen 
Konflikt HK2 zugeordnet und enthalt wiederum die erste Ent- 
scheidungsmoglichkeit El sowie die zweite Entscheidungsmog- 
lichkeit E2 zur Behebung des zweiten harmlosen Konflikts HK2 • 

35 Entsprechen die bisherigen Losungsmoglichkeiten durch ein An- 
nehmen oder Ablehnen vorhandener Konf liktoperationen nicht 
den Zielvorstellungen der Benutzer beztiglich der .letztendli- 
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Chen reintegrierten Datenbank, d.h. kOnnen die Benutzer A und 
B sich nicht auf eine durch die Konflikte beschriebenen Zu- 
stande einigen, so gibt es die Moglichkeit der Annahme einer 
Zwischenlosung oder die Moglichkeit der Auswahl und Annahme 
neuer, nicht im Entscheidungsset enthaltener Operationen. 
Beide Moglichkeiten sollen nachfolgend dargestellt werden. 

Fiir einen Konflikt mit einer Anzahl n den Konflikt definie- 
renden, gleichen Operationen aus einem Set an Datenoperatio- 
nen in nur einer Historie (Konflikte der Typen HK7 II und 
HK8 II) gibt es generell im weiteren beschriebene Auswahlmog- 
lichkeiten von Zwischenzustanden . 

Fur den siebten harmlosen Konflikt HK7 mit n = 1 wird nach- 
15 folgend HK7 I und fur den siebten harmlosen Konflikt HK7 mit 
n > 1 wird nachfolgend HK7 II geschrieben. Fiir den achten 
harmlosen Konflikt HKl mit m = 1 wird nachfolgend HK8 I und 
fUr den achten harmlosen Konflikt HK8 mit n > 1 wird nachfol- 
gend HK8 II geschrieben. 

20 

Eine vierte EntscheidungsmOglichkeit E4 beschreibt dabei eine 
teilweise Annahme und teilweise Ablehnung der Konf liktopera- 
tionen. 

25 Fiir die vierte Entscheidungsmoglichkeit E4 ist eine Prazisie- 
rung vorgesehen, die definiert, wieviele der einseitig auf- 
tretenden Konf liktoperationen angenommen und wieviele abge- 
lehnt werden sollen. Die Entscheidungsmoglichkeiten reichen 
bei einer Anzahl von n Operationen (n ist Element der natUr- 
lichen Zahlen) , von einer Annahme einer Operation und einer 
Ablehnung von n-1 Operationen bis zu einer Annahme von n-1 
und einer Ablehnung von einer Operation. Als Entscheidungs- 
moglichkeit reicht dabei aus, die Anzahl k (0 < k < n) der 
angenommenen Operationen zu definieren. Die Anzahl der abge- 
35 lehnten Operationen errechnet sich dann aus n - k. Die vierte 
Entscheidungsmoglichkeit E4 kann somit folgendermafien spezia- 



30 
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lisiert warden: Die vierte Entscheidungsmoglichkeit E4 be- 
schreibt die Anzahl der angenommenen Konf liktoperationen k. 

Im weiteren wird der funfte kritische Konflikt KK5 mit 
5 n = m = 1 nachfolgend mit KK5 I und ftir den fiinften kriti- 

schen Konflikt KK5 mit n > 1 und m > 1 nachfolgend KK5 II be- 
zeichnet . 

Fur einen fiinften kritischen Konflikt KK5 II mit einer T^zahl 
10 n den Konflikt def inierenden, gleichen Operationen 

changeEigenschaf tAdd bei einer Kopiedatenbank und einer An- 
zahl m den Konflikt def inierenden gleichen Operationen 
changeEigenschaf tDel in einer anderen Kopiedatenbank gestal- 
tet sich die Auswahl der Zwischenzustande schwieriger. 
15 

Da die den Konflikt def inierenden Operationen in der einen 
Historie und die am Konflikt beteiligten Operationen in der 
anderen Historie einander ausloschend sind, kann das gleiche 
Endergebnis durch verschiedene Entscheidungsmoglichkeiten ge- 
20 troffen werden. 

So kann die Riicksetzung einer changeEigenschaf tAdd-Operation 
und die Annahme einer changeEigenschaf tAdd-Operation in der 
einen Kopiedatenbank verbunden mit der Riicksetzung einer 
changeEigenschaftDel-Operation bei einer anderen Kopiedaten- 
bank das gleiche Ergebnis erzielen, wie die Annahme zweier 
changeEigenschaftAdd-Operationen der einen Kopiedatenbank und 
einer changeEigenschaftDel-Operation bei der anderen Kopieda- 
tenbank. Damit alle Entscheidungsmoglichkeiten zwischen den 
3 0 Extrema Ablehnung der Operationen der einen Kopiedatenbank 
und Annahme der Operationen bei der anderen Kopiedatenbank 
(dritte Entscheidungsmoglichkeit E3a/E3b) gegeben sind, 
gleichzeitig aber vermieden wird, daB verschiedene Entschei- 
dungsmoglichkeiten ein gleiches Ergebnis liefern, gibt es die 
35 unten aufgefuhrte Losungsmoglichkeit der funften Entschei- 
dungsmoglichkeit E5, 
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Die fiinfte Entscheidungsmoglichkeit E5 kann durch Ablehnung 
aller Operationen den letzten gemeinsamen Stand zwischen den 
Kopiedatenbanken erzeugen und ermoglicht alle anderen Endzu- 
stande aus den Kombinationen der Operationen, jedoch ohne di 
oben vorliegenden Konf likt zustande , 

Die ftinfte Entscheidungsmoglichkeit E5 beschreibt also die 
teilweise Annahme und teilweise Ablehnung der Konf liktopera- 
tionen bei einer Kopiedatenbank und die Ablehnung der Kon- 
fliktoperationen bei einer anderen Kopiedatenbank. 

Fiir die fiinfte Entscheidungsmoglichkeit E5 sind die Teilent- 
scheidungsmoglichkeiten notwendig, die einerseits definieren 
welche Kopiedatenbank von der teilweisen Annahme und teilwei- 
sen Ablehnung und welche Datenbank von der vollstandigen Ab- 
lehnung betroffen ist und andererseits, wieviele der Konflik- 
toperationen bei einer teilweisen Annahme angenommen und wie- 
viele abgelehnt werden sollen. Die Definition der Anzahl an 
Operationen bei teilweiser Annahme und teilweiser Ablehnung 
kann dabei wie bei der vierten Entscheidungsmoglichkeit E4 
iiber die alleinige Definition der Anzahl der angenoromenen 
Operationen erfolgen. Die Anzahl der angenommenen Operationen 
in einer ersten Kopiedatenbank des ersten Benutzers A werden 
dabei mit i und die Anzahl der angenommenen Operationen der 
Kopiedatenbank des zweiten Benutzers B mit k bezeichnet. So- 
mit sind Detailentscheidungen der funften Entscheidungsmog- 
lichkeit E5: 

Erster Teil E5a der funften Entscheidungsmoglichkeit E5: 
Anzahl der angenommenen Konf liktoperationen der Kopiedaten- 
bank des ersten Benutzers A: 

(1 < i < n), wenn es sich um eine changeEigAdd-Operation 
handelt, 

(1 < k < m) , wenn es sich um eine changeEigDel-Operation 
handelt, und Ablehnung aller Konf liktoperationen der Kopieda- 
tenbank des zweiten Benutzers B. 
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Zweiter Teil E5b der funften Entscheidungsmoglichkeit E5: 
Anzahl der angenommenen Konf liktoperationen der Kopiedaten- 
bank des zweiten Benutzers B: 

(1 < i < n), wenn es sich um eine changeEigAdd-Operation 
handelt , 

(1 < k < m) , wenn es sich um eine changeEigDel-Operation 
handelt und Ablehnung aller Konf liktoperationen der Kopieda- 
tenbank des ersten Benutzers A. 

Eine Auswahlmoglichkeit fur die Erzeugung eines neuen Zustan- 
des bzgl. des Konfliktes wird durch die nachf olgenden Ent- 
scheidungsmoglichkeiten definiert werden, 

Generell ist die Moglichkeit der Erzeugung und Auswahl eines 
sich von den beiden vorliegenden Versionen unterscheidenden 
Zustandes fur alle Konflikte aufier den Konflikten des Typs 
HKl, HK2, HK4, HKIO gegeben. 

Fur eine Erzeugung eines neuen Zustandes bedarf es der Schaf- 
fung einer gemeinsamen Ausgangsposition, d.h. die betreffen- 
de(n) Operation (en) itiussen abgelehnt und beide Kopiedatenban- 
ken beztiglich der von dem Konflikt betroffenen Datenstruktur 
konsistent gemacht werden, Diese Ablehnung der Operationen 
ist bei sich uberschreibenden Operationen des Typs - 
changeEigenschaft {) (HK6, HK4) nicht erf orderlich, da die mit 
dem neuen Zustand erzeugte Operation die alten Operationen 
direkt iiberschreibt • 

Fur einen Konflikt mit einer den Konflikt def inierenden Ope- 
ration aus dem Set an Datenoperationen (Konflikte der Typen 
HK3, HK6, HK7 I, HK8 I und HK9) , fur einen Konflikt mit meh- 
reren den Konflikt def inierenden Operationen aus dem Set an 
Datenoperationen bei nur einer Kopiedatenbank (Konflikte der 
Typen HK5, HK7 II, HK8 II, HKll) sowie ftlr einen Konflikt mit 
mindestens einer den Konflikt def inierenden Operation aus dem 
Set an Datenoperationen bei beiden Kopiedatenbanken 
(Konflikte der Typen KKl, KK8) gibt es folgende Losungs- 
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moglichkeit, die als sechste Entscheidungsmoglichkeit E6 be- 
zeichnet wird. 

Die sechste Entscheidungsmoglichkeit E6 beschreibt die Ableh- 
nung der Konf liktoperation (en) und Auswahl neuer Operati- 
on (en) . 

Fiir die beidseitige Anderung einer Beziehung {KK2) oder die 
beidseitige Anderung eines Eintrages in einer geordneten Auf- 
zahlung (KK7) bezieht sich die Ablehnung dabei, im Gegensatz 
zur zweiten Entscheidungsmoglichkeit E2 (Ablehnung aller Ope- 
rationen) nur auf die Erzeugeroperationen der neuen Beziehun- 
gen bzw. der neuen Eintrage. Die gemeinsame Loschoperation 
der alten Beziehung oder des alten Eintrages bleibt unbe- 
ruhrt. Fiir den dritten kritischen Konflikt KK3 und den achten 
kritischen Konflikt KK8 gibt es bei der sechsten Entschei- 
dungsmoglichkeit E6 nur die Moglichkeit, die createBeziehung- 
Operation oder die changeEigenschaf tInsert-Operation zu an- 
dern. Die gemeinsame Loschoperation bleibt unberuhrt. 

Fur die Definition eines neuen Zustandes eines Konflikts vom 
Typ HK7, HK8 oder KK5 werden die Anzahl der 
changeEigenschaf tAdd-Oper at ionen und 

changeEigenschaftDel-Operationen ebenfalls mit i und k be- 
schrieben 

(i, wenn es sich urn changeEigAdd-Operationen handelt und 
k, wenn es sich um changeEigDel-Operationen handelt) • 

Fiir .die Auswahl eines neuen Zustandes und die Erzeugung der 
dafiir notwendigen Operationen sind Interaktionen auf der 
Oberflache des Anwendungsprogramms iiblich. Besteht die Mog- 
lichkeit einer Auswahl eines neuen Zustandes nur Uber eine 
komplexe Interaktion und betref fen die durch die Interaktion 
erzeugten Operationen auch noch andere, nicht geloste Kon- 
flikte, so besteht die Moglichkeit 
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a) mit dem Entscheidungsset die anderen betroffenen Konflikte 
ebenfalls zu losen Oder 

b) die Erzeugung des neuen Zustandes auf einen spateren Zeit- 
punkt, d,h. nach der Reintegration und wahrend der gekop- 
pelten Weiterarbeit zu verschieben. 

Sollen nach a) andere betroffene Konflikte ebenfalls gelost 
werden, so ist vorher die Ablehnung der Operationen des Kon- 
fliktsets notwendig, wenn es sich um Konflikte vom Typ HK6 
und KK4 handelt und die Operationen keine sich iiberschreiben 
den Operationen sind. 

Fig. 4 zeigt die Entscheidungssets ESI, ES2, ES3, ES4, ESS, 
ES6, ES7, ESS, ES9, ESIO, ESll, ES12, ES13, ES14, ES15, ES16 
ES17, ES18, ES19, ES20, ES21, ES22, die den jeweiligen Kon- 
flikten zugeordnet sind. 

Dem sechsten harmlosen Konflikt HK6 ist ein sechster Ent- 
scheidungsset ES6 zugeordnet, der die erste Entscheidungsmog 
lichkeit El, die zweite Entscheidungsmoglichkeit E2 sowie di 
sechste Entscheidungsmoglichkeit E6 enthalt. 

Ein zwolftes Entscheidungsset ES12 ist dem ersten kritischen 
Konflikt KKl zugeordnet. Der zwolfte Entscheidungsset ES12 
enthalt vier mogliche Entscheidungen, die zweite Entschei- 
dungsmoglichkeit E2, den ersten Teil E3a der dritten Ent- 
scheidungsmoglichkeit E3, den zweiten Teil E3b der dritten 
Entscheidungsmoglichkeit E3 sowie die sechste Entscheidungs- 
moglichkeit E6. 

Die weiteren Entscheidungssets sind in Fig, 4 dargestellt und 
sollen zur Vereinf achung im folgenden anhand der folgenden 
Liste dargestellt werden: 

• Dem ersten harmlosen Konflikt HKl, dem zweiten harmlosen 
Konflikt HK2, dem vierten harmlosen Konflikt HK4 sowie dem 
zehnten harmlosen Konflikt HKIO sind jeweils Entscheidungs- 
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sets zugeordnet, die die erste Entscheidungsmoglichkeit El 
sowie die zweite Entscheidungsmoglichkeit E2 umfassen. 

• Dem dritten harmlosen Konflikt HK3, dem fiinften harmlosen 
Konflikt HK5, dem sechsten harmlosen Konflikt HK6, dem er- 
sten Typ HK7 I des siebten harmlosen Konflikts HK7, dem er- 
sten Typ HK8 I des achten harmlosen Konflikts HK8, dem 
neunten harmlosen Konflikt HK9 sowie dem elften harmlosen 
Konflikt HKll sind jeweils Entscheidungssets zugeordnet, 
die die erste Entscheidungsmoglichkeit El, die zweite Ent- 
scheidungsmoglichkeit E2 sowie die sechste Entscheidungs- 
moglichkeit E6 enthalten. 

• Dem zweiten Typ HK7 II des siebten harmlosen Konflikts HK7 
dem zweiten Typ HK8 II des achten harmlosen Konflikts HK8, 
dem ersten kritischen Konflikt KKl, dem zweiten kritischen 

15 Konflikt KK2, dem dritten kritischen Konflikt KK3, dem 

vierten kritischen Konflikt KK4, dem ersten Typ KK5 I des 
fanften kritischen Konflikts KK5, dem sechsten kritischen 
Konflikt KK6, dem siebten kritischen Konflikt KK7 und dem 
kritischen Konflikt KK8 sind jeweils Entscheidungssets zu- 
20 geordnet, die die zweite Entscheidungsmoglichkeit E2, den 
ersten Teil E3a der dritten Entscheidungsmoglichkeit E3, 
den zweiten Teil E3b der dritten Entscheidungsmoglichkeit 
E3 sowie die sechste Entscheidungsmoglichkeit E6 enthalten. 
Dem zweiten Typen KK5 II des fiinften kritischen Konflikts 
KK5 ist ein Entscheidungsset mit sechs moglichen Entschei- 
dungen, der zweiten Entscheidungsmoglichkeit E2, dem erstei! 
Teil E3a der dritten Entscheidungsmoglichkeit E3, dem zwei- 
ten Teil E3b der dritten Entscheidungsmoglichkeit E3, dem 
ersten Teil E5a der ftlnften Entscheidungsmoglichkeit E5, 
dem zweiten Teil E5b der ftlnften Entscheidungsmoglichkeit 
E5 sowie der sechsten Entscheidungsmoglichkeit E6, zugeord- 
net . 

Dem zweiten Typ HK7 II des siebten harmlosen Konflikts HK7 
und dem zweiten Typ HK8 II des achten harmlosen Konflikts 
HK8 ist jeweils ein Entscheidungsset mit vier jnoglichen 
Entscheidungen, der ersten Entscheidungsmoglichkeit El, der 
zweiten Entscheidungsmoglichkeit E2, der vierten Entschei- 



25 



30 



35 





GR 98 P 2167 



43 

dungsmoglichkeit E4 sowie der sechsten Entscheidungsmog- 
lichkeit E6 zugeordnet, 

Einschrankungen von Entscheidungsmbglichkeiten 

Es ist zu bemerken, daiJ die korrekte AusfUhrung einzeiner 
Entscheidungen zum Vorhandensein eines Datenelements oder 
mehrerer Dateneleinente in beiden Kopiedatenbanken abhangig 
ist. 

Beispielsweise mussen fur eine Annahme bei dem dritten harm- 
losen Konflikt HK3A beide in der Beziehungsoperation in Kon- 
flikt iiber ihre Identifier bezeichneten Datenelemente auch in 
der Kopiedatenbank des Benutzers B vorhanden sein. Fehlt ei- 
nes der Datenelemente oder fehlen gar beide, so ist diese 
Entscheidung uber eine Annahme der Operation nicht moglich. 

Somit ist erkennbar, daB zwischen einzelnen Konflikten Abhan 
gigkeiten bestehen konnen. 

Eine Abhangigkeit eines Konflikts zu Konflikten des Typs 
HKIA, HKIB, HK2A oder HK2B bezuglich seiner Entscheidungsmog 
lichkeiten ist wie folgt definiert: 

Abhangiger Konflikt: 

Ein Konflikt ist von dem ersten harmlosen Konflikt HKl oder 
dem zweiten harmlosen Konflikt HK2 dann abhangig, wenn seine 
Entscheidungsmoglichkeiten durch das Vorhandensein eines er- 
sten harmlosen Konflikts HKl oder eines zweiten harmlosen 
Konflikts HK2 eingeschrankt werden. 

Eine Abhangigkeit AK eines Konflikts ist wie folgt definiert; 
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Abhangigkeit AK eines Konf likts : 

Eine Abhangigkeit AK eines Konf liktes Kl (EHA, EHB, GH) von 
einem Konflikt Kl (EHA, EHB, GH) ist ein 4-Tupel 

AK (Kl, K2) ^ (id, ktyp, kidl, kid2) 

• id ist ein systexnweit eineindeutiger Identifier ( siehe auch 
Definition eines Datenelementes ) 

• ktyp € {HKIA, HKIB, HK2A, HK2B} 

• kidl = Kl.id 

• kid2 = K2,id. 

Ein Abhangigkeitsregister AKR ist wie folgt definiert: 
Abhangigkeitsregister AKR: 

Ein Abhangigkeitsregister AKR zweier Historien EHA und EHB 
und einer gemeinsamen Historie GH ist ein 1-Tupel 

AKR (EH^, EHb, GH) dej_ (abhangigkeitsids ) 

• abhangigkeitsids sind die Identifier aller erkannten Abhan- 
gigkeiten der Historien EH;^ und EHg und der gemeinsamen Hi- 
storie GH. 

Alle Einschrankungen von Entscheidungsmoglichkeiten durch 
vorhandene Konflikte des ersten harmlosen Konflikts HKl und 
des zweiten harmlosen Konflikts HK2 werden zu Beginn der Kon- 
fliktlosung auf der Grundlage der Abhangigkeiten AK erkannt 
und markiert. 

Dazu dient der in der Konf liktdef inition fur jeden Konflikt 
eingefuhrte Parameter der Entscheidungseinschrankungen. Nach- 
folgend werden alle moglichen Einschrankungen beschrieben. 

Der erste harmlose Konf likt ^HKl beeintrachtigt die EntSGhei- 
dungsmoglichkeiten von Konflikten mit Operationen innerhalb 
der eigenen Historie. Zu diesen abhangigen Konflikten gehoren 
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alle, die eine createBeziehung-Operation oder eine Eigen- 
schaf tsanderung mit dem erzeugten Datenelement enthalten, Da- 
bei werden bei harmlosen Konflikten HK6, HKll mit Eigen- 

schaf tsoperationen 2u diesem Datenelement die Entscheidungen 
urn eine Annahme und eine Erzeugung eines neuen Zustandes mi- 
nimiert. 

Die Entscheidungsmoglichkeiten der kritischen Konflikte KKl, 
KK2 und KK3 mit Beziehungsoperationen mit dem erzeugten Da- 
tenelement werden um die Moglichkeit der Annahme der Opera- 
tionen (-E3a, -E3b) der Kopiedatenbank reduziert, in dessen 
Historie die createElement-Operation steht. Die Entschei- 
dungsmoglichkeiten fur den dritten harmlosen Konflikt HK3 und 
den fiinften harmlosen Konflikt HK5 mit Beziehungsoperationen 
mit dem erzeugten Datenelement werden um die Entscheidung der 
Obernahme und/oder der Erzeugung eines neuen Zustandes redu- 
ziert. Kritische Konflikte mit Eigenschaf tsoperationen erfah- 
ren keine Veranderungen ihrer Entscheidungsmenge 
(Entscheidungssets) . 

Ein zweiter harmloser Konflikt HK2 beeintrachtigt die Ent- 
scheidungsmoglichkeit von Konflikten beider Kopiedatenbanken* 
Die harmlosen Konflikte zur Veranderung von Eigenschaf ten 
HK6, HKll werden wie bei dem ersten harmlosen . Konflikt 

HKl behandelt. Die harmlosen Konflikte mit Beziehungsopera- 
tionen (HK4, HK5) in der Historie der deleteElement-Operation 
besitzen keine Entscheidungsmoglichkeit zur Ablehnung mehr 
und die Entscheidungen zur harmlosen Beziehungskonf likten der 
anderen Kopiedatenbank HK3, HK5 werden um die Moglichkeit der 
Obernahme und/oder Erzeugung eines neuen Zustandes minimiert. 
Die kritischen Konflikte mit Beziehungsoperationen der Kopie- 
datenbank ohne die deleteElement-Operation werden um die Mog- 
lichkeit des RUcksetzens und/oder der Annahme der Operationen 
reduziert. Kritische Konflikte mit Eigenschaf tsoperationen 
erfahren auch hier keine Veranderung ihrer Entscheidungsmen- 
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Eine gemeinsame deleteElement-Operation, die in der gemeinsa- 
men Historie GH enthalten ist und keinen Konflikt darstellt, 
verringert in speziellen Fallen die Entscheidungsmoglichkei- 
ten. So konnen alle kritischen Konflikte KK2 und KK3 mit Be- 
ziehungsoperationen, in denen das Zieldatenelement der ge- 
meinsamen deleteBeziehung-Operation dem beidseitig geloschten 
Datenelement entspricht, nicht mehr riickgesetzt werden. 

Abhangige Konflikte mit einer oder mehreren Bezlehungsoper- 
tionen (HK3, HK4, HK5, KKl, KK2, KK3) , d.h. mit mehreren ver- 
zeichneten Identifiern und damit mehreren beteiligten Da- 
tenelementen, konnen gleichzeitig mehrere Abhangigkeiten auf-^ 
weisen. Dabei kann es pro auftretenden Identifier in einem M 
Konflikt nur eine Abhangigkeit geben. Ein abhangiger Konflikt 
mit mehreren Identifiern kann einerseits mehrere Abhangigkei- 
ten zu Konflikten desselben Konflikttyps (zum Beispiel zu 
zwei Konflikten des ersten harmlosen Konflikts HKla) und an- 
dererseits mehrerer Abhangigkeiten zu Konflikten unterschied- 
licher Konf likttypen (z.B. zu einem Konflikt vom Typ HKla und 
zu einem Konflikt vom Typ HKlb) aufweisen. Beispielsweise 
kann ein abhangiger Konflikt vom Typ HK3a zwei Abhangigkeiten 
zu zwei Konflikten des Typs HKla haben, namlich eine mit dem 
Identifier idl und eine mit dem Identifier id2 . Der zweite 
kritische Konflikt KK2 kann gleichzeitig eine Abhangigkeit zu 
dem zweiten harmlosen Konflikt HK2a, zu dem ersten harmlosen 
Konflikt HKla und zu dem ersten harmlosen Konflikt HKIB auf- 
weisen. 



Durch die Abhangigkeit der Identifier zu einem Konflikt vom 
Typ HKl Oder HK2 kann es maximal pro Konflikt vom Typ HK5, 
KKl, KK2 Oder KK3 drei EinschrSnkungen geben. Alle Konflikte 
vom Typ HK3A, HK3B, HK4A, HK4B, HK5A und HK5B konnen gleich- 
zeitig mehrere Abhangigkeiten zu Konflikten desselben oder 
unterschiedlichen Typs haben. Konflikte der Typen KKl, KK2, 
KK3A und KK3B konnen dagegen gleichzeitig mehrere Abhangig- 
keiten zu Konflikten verschiedener Typen aufweisen^ Es kOnnen 
jedoch bei mehrfach vom selben Konflikttyp abhangigen Kon- 
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flikten auch die gleichen Einschrankungen der Entscheidungs- 
moglichkeiten mehrfach auftreten. So sind fUr einen Konflikt 
vom Typ HK3A gleichzeitig zwei Abhangigkeiten bei Vorhanden- 
sein eines Konflikts vom Typ HKIA oder eines vom Typ HK2B 
moglich und die Entscheidungen werden jeweils um die erste 
Entscheidung El minimiert. 

Die sich zu manchen abhangigen Konflikten ergebenden mehrfa- 
chen Einschrankungen mit den gleichen Entscheidtingsmoglich- 
keiten bedurfen keiner gesonderten Betrachtung. Jede dieser 
Entscheidungseinschrankungen wird betrachtet, als ob es eine 
eigene, spezielle Einschrankung ist. Es werden somit alle 
mehrfachen Einschrankungen, wie andere auch, im Konflikt ver- 
merkt. Bei einer Losung eines Konflikts des Typs HKl und HK2 
in der Art, dafi eine der mehrfach vorkommenden Einschrankun- 
gen aufgehoben wird, bleiben die restlichen dieser Einschran- 
kungen erhalten. Erst wenn durch verschiedene Konf liktlosun- 
gen keine der mehrfachen Einschrankungen mehr vorhanden ist, 
kann eine Entscheidung dieser Art vorgenommen werden. Dies 
gilt unabhangig davon, ob die Einschrankung einmal oder mehr- 
mals vorhanden war. 

Die einmalig zu Beginn der Reintegration erkannten Einschran- 
kungen durch Abhangigkeiten der Konflikte zu Konflikten des 
Typs HKl und HK2 werden abhangig von der Losung der Konflikte 
des Typs HKl und HK2 wahrend der Reintegration dynamisch ge- 
andert. So kommt es abhangig vom Typ der abhangigen Konflikte 
und der jeweiligen Losungsentscheidung der createElement- 
Operation und deleteElement-Operation zu den nachf olgenden 
Anderungen der Entscheidungseinschrankungen: 

a) Die Annahme einer createElement-Operation (erst~e Entschei- 
dung El zu einem Konflikt vom Typ HKl) verursacht bei alien 
von der Operation abhangigen Konflikten eine Rucksetzung 
der Entscheidungseinschrankungen, d.h. eine Erweiterung der 
Entscheidungsmoglichkeiten. 

b) Die Ablehnung einer deleteElement-Operation (zweite Ent- 
scheidung E2 zu einem Konflikt vom Typ HK2) verursacht 
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ebenfalls eine Riicksetzung der Entscheidungseinschrankun- 
gen, d.h. eine Erweiterung der Entscheidungsmoglichkeiten 
fur die von diesem Konflikt abhangigen Konflikte. 

c) Die Ablehnung einer createElement-Operation (zweite Ent- 
scheidung E2 zu einem Konflikt vom Typ HKl ) fuhrt zur Bei- 
behaltung der bereits vorgenommenen Entscheidungseinschran- 
kungen der von diesem Konflikt abhangigen Konflikte. Es an- 
dern sich somit keine Entscheidungsmoglichkeiten. 

d) Die Annahme einer deleteElement-Operation (erste Entschei- 
dung El zu einem Konflikt vom Typ HK2) fUhrt zur Beibehal- 
tung der bereits vorgenommenen Entscheidungseinschrankungen 
der von diesem Konflikt abhangigen Konflikte. Es andern ^ 
sich somit keine Entscheidungsmoglichkeiten. m 

Eine einseitig erzeugte Anomalie kann Ober jeweils zwei vor- 
handene Konflikte in einer Historie erkannt werden. Dabei 
gibt es die Moglichkeiten der Konf liktpaare HK5Aa/HK5Ab, 
HK4A/HK3A, HK4A/HK5A. Bei einem Konflikt vom Typ HK5Aa ist 
die deleteBeziehung-Operation und bei einem Konflikt vom Typ 
HK5Ab ist die createBeziehung-Operation an der Anomalie be- 
teiligt . 

Fur Anomalien, die durch Veranderungen auf der Kopiedatenbank 
des zweiten.Benutzers B entstehen, gelten die gleichen Mog- 
lichkeiten: HK5Ba/HK5Bb, HK4B/HK3B, HK4B/HK5B. Allen Kon- 
fliktpaaren ist dabei gemeinsam, dafi es eine deleteBeziehung- 
Operation mit einem Identifier idl als Quelldatenelement und 
einem Identifier id2 als Zieldatenelement in einem der beiden 
Konflikte gibt und die gleichen Identifier vertauscht als 
Quelldatenelement und Zieldatenelement in einer createBezie- 
hung-Operation des anderen Konfliktes auftreten. 

Die Annahme des Konflikts der einseitigen Anomalie, wie oben 
beschrieben, mit der createBeziehung-Operation verhindert die 
Ablehnung des Konflikts der einseitigen Anomalie mit der de- 
leteBeziehung-Operation einer Ablehnung des Konf 1 ikts der 
einseitigen Anomalie mit der deleteBeziehung-Operation dage- 
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gen verhindert die Annahme des Konflikts der Anomalie mit der 
createBeziehung-Operation. Die Anderung einer der beiden Kon- 
flikte vermindert die Entscheidungsmoglichkeiten des anderen 
Konfliktes nicht. 

Somit ergibt sich, daB eine einseitig erzeugte Anomalie ge- 
richteter Beziehungen durch eine Ablehnung beider Konflikte, 
einer Annahme beider Konflikte, einer verschiedenen Anderung 
beider Konflikte Oder einer Veranderung einer der Konflikte 
und einer T^nahme oder Ablehnung des anderen Konflikts losbar 
ist . 

Eine beidseitig erzeugte Anomalie gerichteter Beziehungen ist 
durch die Entscheidung einer der beiden Konflikte und eine 
davon verschiedene Entscheidung des anderen Konfliktes los- 
bar . 

Zur Vermeidung der Entstehung einer Anomalie (sogenannte 
Pseudo-Anomalie) , wie oben beschrieben, sind folgende Ein- 
schrankungen der Entscheidungsmoglichkeiten vorgesehen: 

a) Nach einer Annahme eines Konflikts mit der createBeziehung- 
Operation, die das gemeinsame Datenelement idl als Zielda- 
tenelement enthalt (createBeziehung21 ) darf es fur den Kon- 
flikt mit den zwei createBeziehung-Operationen, die das ge- 
meinsame Datenelement als Quelldatenelement enthalten, kei- 
ne Entscheidungsmoglichkeit der sechsten Entscheidungsmog- 
lichkeit E6 mit einer Ersetzung des Zieldatenelements (idx 
Oder idz) durch das Quelldatenelement 

id2 (createBeziehung21 ) mehr geben. 

b) Nach einer erfolgten sechsten Entscheidung E6 aufgrund der 
s*echsten Entscheidungsmoglichkeit E6 und der Auswahl eines 
neuen Zieldatenelements id2 fur den Konflikt mit den zwei 
createBeziehung-Operationen, die das gemeinsame Datenele- 
ment idl als Quelldatenelement enthalten, darf keine Annah- 
me des Konfliktes mit der createBeziehung-Operation mit dem 
gemeinsamen Datenelement idl als Zieldatenelement 
(createBeziehung21) mehr moglich sein. 
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Wie oben beschrieben, warden iiti Rahmen dieses Verfahrens die 
Entscheidungsmoglichkeiten von Konflikten entsprechend deren 
Abhangigkeiten, Anomalien und Pseudo-Anomalien eingeschrankt 

Nach jeder Entscheidung zu einem Konflikt wird eine Anderung 
der Entscheidungsmoglichkeiten der von deiti eben gelosten Kon 
flikt abhangigen oder sich in einer gemeinsamen Anomalie bzw 
Pseudo-Anomalie mit diesem Konflikt befindlicheh Konflikte 
entsprechend den Abhangigkeiten, Anomalien und Pseudo- 
Anomalien vorgenommen. 

Fur jeden Konflikt wird, wie oben beschrieben, eine Entschei 
dung getroffen. Die Entscheidung kann auf unterschiedliche 
Weise erfolgen. Eine Ubersicht uber mogliche Entscheidungsva- 
riationen ist in [1] zu finden, 

Im Rahmen dieses Ausf Uhrungsbeispiels ist vorgesehen, daB ei- 
ne Datenbank oder Kopiedatenbank als Ref erenzdatenbank ange- 
sehen wird, und der Abgleich gemaB der Ref erenzdatenbank er- 
folgt . 

Es wird also, wie in Fiq.l durch eine rekursive Schleife iiber 
einem Oberprilfungsschritt (Schritt 105) dargestellt ist, 
uberprtift, ob noch ein Konflikt vorliegt und somit eine Ent- 
scheidung getroffen werden muJ5 . Ist eine Entscheidung noch zu 
treffen, so wird diese getroffen. Sind keine Konflikte mehr 
vorhanden, so wird ein letzter Verf ahrensschritt 
(Schritt 106) durchgef Uhrt , das Abspeichern der reintegrier- 
ten Datenbank, welche keine Inkonsistenzen mehr aufweist. 

Die konsistenzfreie Datenbank wird wieder an alle weiteren 
Rechner, die mit dem ersten Rechner 200 verbunden sind, Uber- 
tragen (Schritt 107) . 

Damit besitzen alle Rechner eine konsistente Kopiedatenbank. 



GR 98 P 2167 



51 

Iiti weiteren werden einige Alternativen zu dem oben beschrie- 
benen Ausf tihrungsbeispiel dargestellt: 

Die Erkennung von Inkonsistenzen kann auch nach einer vorgeb- 
baren Anzahl erfolgter Behebung einer Inkonsistenz durch die 
Suche nach einer weiteren Inkonsistenz erfolgen. Dies kann 
dahingehend erweitert werden, daii erneut nach jeder Behebung 
einer Inkonsistenz die Suche nach einer nachsten Inkonsistenz 
und deren Behebung erfolgt, 

Es ist ferner moglich, daii durch den ersten Rechner gemafi dem 
oben dargestellten Verfahren eine Folge von Korrekturbef ehlen 
(Korrektursequenzen) ermittelt wird, die jeweils dem Rechner, 
dessen Kopiedatenbank auf Inkonsistenzen hin liberpriift wurde, 
ubermittelt wird und der jeweilige Rechner anhand der Korrek- 
tursequenz seine Kopiedatenbank an die Datenbank abgleicht, 

Es ist ferner in einer alternativen Ausfuhrungsform ebenfalls 
moglich, einem Benutzer oder mehreren Benutzern die Entschei- 
dung zu iiberlassen, d.h. die Entscheidungsmoglichkeiten wer- 
den einem Benutzer auf dem Bildschirm dargestellt, und der 
Benutzer wahlt tiber die Tastatur oder die Computermaus die 
von ihm gewiinschte Entscheidung aus, die dann von dem Rechner 
durchgefiihrt wird. 
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In diesem Dokument ist folgende Verof f entlichung zitiert 
[1] DE 196 07 132 Al 
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Patentansprtiche 

1. Verfahren zur rechnergestutzten Behebung mindestens einer 
Inkonsistenz in einer Datenbankmenge, die eine Datenbank so- 
wie mindestens eine Kopiedatenbank der Datenbank aufweist, 
welche Inkonsistenz durch Anderung der Datenbank und/oder der 
Kopiedatenbank entsteht/ 

a) bei dem mindestens ein Teil der Operationen, die eine In- 
konsistenz erzeugen konnen, definierten Konf likttypen zu- 
geordnet ist, 

b) bei dem jedem Konflikttyp ein Entscheidungsset zugeordnet 
ist, mit dem mogliche Entscheidungen angegeben werden, 
mit denen eine durch mindestens eine Operation des jewei- 
ligen Konflikttyps erzeugte Inkonsistenz behoben werden 
kann, 

c) bei dem die Inkonsistenz unter Verwendung des Entschei- 
dungssets behoben wird. 

2. Verfahren nach Anspruch 1, 

bei dem mehrere Inkonsistenzen behoben werden. 

3. Verfahren nach Anspruch 1 oder 2, 

bei dem jedem Konflikttyp ein Entscheidungsset zugeordnet 
ist, mit dem mogliche Entscheidungen angegeben werden, mit 
denen eine durch mehrere Operationen des jeweiligen Konflikt- 
typs erzeugte Inkonsistenz behoben werden kann, 

4. Verfahren nach einem der Anspriiche 1 bis 3, 

bei dem die Datenbankmenge mehrere Kopiedatenbanken der Da- 
tenbank aufweist. 

5. Verfahren nach einem der Anspruche 1 bis 4, 

bei dem vor der Behebung der Inkonsistenzen alle Inkonsisten- 
zen und deren Abhangigkeiten voneinander, Anomalien und Pseu- 
do-Anomalien ermittelt werden. 

6. Verfahren nach einem der Anspruche 1 bis 5, 
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bei dem das Entscheidungsset eines Konfliktes wahrend des 
Verfahrens verandert wird. 

7. Verfahren nach einem der Anspruche 1 bis 6, 

bei dem die Anderung des jeweiligen Entscheidungssets abhan- 
gig von Abhangigkeiten von Inkonsistenzen erfolgt. 

8. Verfahren nach einem der Ansprtiche 1 bis 1, 

bei dem nach einer vorgebbaren Anzahl von behobenen Inkonsi- 
stenzen die Datenbankmenge auf weitere Inkonsistenzen und de- 
ren Abhangigkeiten, Anomalien und Pseudo-Anomalien hin unter- 
sucht wird. ^ 

9. Verfahren nach einem der Anspruche 1 bis 8, 

bei dem die Datenbankmenge eine obj ektorientierte Datenbank 
enthalt, 

10. Verfahren nach einem der Anspruche 1 bis 9, 
eingesetzt im Rahmen der objektorientierten Sof twareentwick- 
lung . 

11. Verfahren nach einem der Anspruche 1 bis 9, 
eingesetzt im Rahmen der Erstellung eines strukturierten 
elektronischen Dokuments. 

12. Anordnung zur Behebung mindestens einer Inkonsistenz in 
einer Datenbankmenge, die eine Datenbank sowie mindestens ei- 
ne Kopiedatenbank der Datenbank aufweist, welche Inkonsistenz 
durch Anderung der Datenbank und/oder der Kopiedatenbank ent- 
steht/ 

mit mindestens einem Prozessor, der derart eingerichtet ist, 
daJi folgende Schritte durchfiihrbar sind: 

a) mindestens ein Teil der Operationen, die eine Inkonsi- 
stenz erzeugen konnen, ist definierten Konf likttypen zu- 
geordnet, 

b) jedem Konflikttyp ist ein Entscheidungsset zugeordnet, 
mit dem mogliche Entscheidungen angegeben werden, mit de- 
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nen eine durch laindestens eine Operation des jeweiligen 
Konf likttyps erzeugte Inkonsistenz behoben warden kann, 
c) die Inkonsistenz wird unter Verwendung des Entscheidungs 
sets behoben. 

13. Anordnung nach Anspruch 12, 

bei der der Prozessor derart eingerichtet ist, dafi mehrere 
Inkonsistenzen behoben werden. 

14. Anordnung nach Anspruch 12 oder 13, 

bei der der Prozessor derart eingerichtet ist, daB jedem Kon 
flikttyp ein Entscheidungsset zugeordnet ist, mit dem itiogli- 
che Entscheidungen angegeben werden, mit denen eine durch 
mehrere Operationen des jeweiligen Konf likttyps erzeugte In- 
konsistenz behoben werden kann, 

15. Anordnung nach einem der Anspruche 12 bis 14, 

bei der der Prozessor derart eingerichtet ist, daB die Daten- 
bankmenge mehrere Kopiedatenbanken der Datenbank aufweist. 

16. Anordnung nach einem der Anspruche 12 oder 15, 

bei der der Prozessor derart eingerichtet ist, daB vor der 
Behebung der Inkonsistenzen alle Inkonsistenzen und deren Ab- 
hangigkeiten voneinander, Anomalien und Pseudo-Anomalien er- 
mittelt werden. 

17. Anordnung nach einem der Anspruche 12 bis 16, 

bei der der Prozessor derart eingerichtet ist, daB das Ent- 
scheidungsset eines Konfliktes wahrend des Verfahrens veran- 
dert wird. 

18. Anordnung nach einem der Anspruche 12 bis 17, 

bei der der Prozessor derart eingerichtet ist, daB die Ande- 
rung des jeweiligen Entscheidungssets abhangig von Abhangig- 
keiten von Inkonsistenzen erfolgt. 

19. Anordnung nach einem der Anspriiche 12 bis 18, 
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bei der der Prozessor derart eingerichtet ist, daB nach einer 
vorgebbaren Anzahl von behobenen Inkonsistenzen die Daten- 
bankmenge auf weitere Inkonsistenzen und deren Abhangigkei- 
ten, Anomalien und Pseudo-Anortialien hin untersucht wird. 

20. Anordnung nach einem der Anspruche 12 bis 19, 

bei der der Prozessor derart eingerichtet ist, dafi die Daten- 
bankmenge eine obj ektorientierte Datenbank enthalt. 

21. Anordnung nach einem der Anspruche 12 bis 20, 

eingesetzt im Rahmen der objektorientierten Sof twareentwick- 
lung. 

22. Anordnung nach einem der Anspruche 12 bis 21, 
eingesetzt im Rahmen der Erstellung eines strukturierten 
elektronischen Dokuments. 

23. Satz mehrerer Anordnungen zur Behebung mindestens einer 
Inkonsistenz in einer Datenbankmenge, die eine Datenbank so- 
wie mindestens eine Kopiedatenbank der Datenbank aufweist, 
welche Inkonsistenz durch Anderung der Datenbank und/oder der 
Kopiedatenbank entsteht, 

bei dem jede Anordnung mindestens einen Prozessor aufweist, 
der derart eingerichtet ist, dal3 folgende Schritte durchfUhr- 
bar sind: 

a) mindestens ein Teil der Operationen, die eine Inkonsi- 
stenz erzeugen konnen, ist definierten Konf likttypen zu- 
geordnet, 

b) jedem Konflikttyp ist ein Entscheidungsset zugeordnet, 
mit dem mSgliche Entscheidungen angegeben werden, mit de- 
nen eine durch mindestens eine Operation des jeweiligen 
Konflikttyps erzeugte Inkonsistenz behoben werden kann, 

c) die Inkonsistenz wird unter Verwendung des Entscheidungs- 
sets behoben, und 

bei dem die Anordnungen miteinander koppelb_ar sind^_ 
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Zusammenf assung 

Verfahren, Anordnung und Satz mehrerer Anordnungen zur Behe- 
bung von Inkonsistenzen in einer DatenbanJcmenge, die eine Da- 
tenbank sowie mindestens eine Kopiedatenbank der Datenbank 
aufweist 

Zur Behebung mindestens einer Inkonsistenz in einer Daten- 
bankmenge, die eine Datenbank sowie mindestens "eine Kopieda- 
tenbank der Datenbank aufweist, welche Inkonsistenz durch An- 
derung der Daten in der Datenbank oder in der Kopiedatenbank 
entsteht, ist mindestens ein Teil der Operationen, die eine 
Inkonsistenz erzeugen konnen, definierten Konf likttypen zuge- 
ordnet. Jedem Konflikttyp ist ein Entscheidungsset zugeord- 
net, mit dem mogliche Entscheidungen angegeben werden, mit 
denen eine durch eine Operation des jeweiligen Konflikttyps 
erzeugte Inkonsistenz behoben werden kann. Die Inkonsistenz 
wird unter Verwendung des Entscheidungssets behoben. Eine 
fehlerfreie Behebung von Inkonsistenzen wird durch Anpassung 
des Entscheidungssets an die jeweilige Situation gewahrlei- 
stet . 
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